Patryk’s blog delves into Google Authenticator:
When you’re accessing services over the WEB – let’s pick GMail as an example – couple of things have to happen upfront:
- The server you’re connecting to (GMail in our example) has to get to know who you are.
- Only after getting to know who you are it’s able to decide what resources you are allowed to access (e.g. your own email inbox, your Calendar, Drive etc.).
Step 1 above is called authentication. Step 2 is authorization (server can authorize only after successful authentication).
Using apps like Google Authenticator is all about step 1. And you can think of that step as logging in to your GMail account.
What problem are we solving?
Authentication is typically performed using one (or more) of the following approaches:
- What you know? – The server “tests you” by asking about something only you are supposed to know (e.g. username and password). That’s the most common approach. You’re presented with a login form where you enter your credentials.
- What you have? – The server tests you by making sure you have something that you’re supposed to have (e.g. a secret of sorts embedded in the bowels of Google Authenticator installed on your smartphone). Only you are supposed to have physical access to your phone. If you don’t (in other words you can’t open the app and type the code), authentication fails.
- Who you are – The server tests your biometrics. This could be done using a fingerprint reader in your smartphone/laptop, face ID in your iPhone etc.
Read more in the post here.