How login works: Google sign-in, OAuth and passkeys, explained simply
Contents24
Every time you open an app and it already knows it's you, a few quiet checks have happened in the background. This post walks through those checks using one student, Asha, and the Edme App on her phone.
Asha is preparing for UPSC. Most of her studying happens on her phone: on the bus, between classes, late at night. She uses the Edme App for lessons and practice tests, and she'd like it to plan study time around the events in her Google Calendar. We'll follow her from the moment she logs in.
how an app knows which account is yours,
why logging in and being allowed to open something are two different checks,
what really happens when you tap "Continue with Google",
why an app asks for permission before reading your calendar, and
how a passkey lets you log in with just your fingerprint, and why fake websites can't steal it.
1. Proving the account is yours
When Asha opens the Edme App, the app has to answer one question before anything else: is this really Asha? If it skipped that question, anyone could open her notes, her test scores and her saved answers.
Authentication means checking that the person in front of the screen is really in control of the account they're trying to open.
The oldest way to do this is an email and a password. The email tells the app which account. The password is the evidence that you're allowed into it. An OTP sent to your phone, your fingerprint and a passkey are other kinds of evidence. They all answer the same question.
Logged in is not the same as allowed in
Once the app knows it's Asha, it asks a second, separate question: what is she allowed to see? This is called authorization.
Think of your college. Showing your ID card at the gate proves you're a student there. That's authentication. Whether you can walk into the staff room is a different rule altogether. That's authorization.
In the Edme App it works the same way. Asha has bought the Prelims course, so she can open every Prelims lesson. She hasn't bought the Mains course, and she isn't a teacher, so those screens stay locked for her even though she's logged in.
The question | What it's called |
|---|---|
Which account does this person control? | Authentication |
What is this account allowed to do? | Authorization |
That means your login worked fine. It's the second check, the permission check, saying no. Logging out and back in won't change it; buying the course or getting the right role will.
2. Passwords, and why the app doesn't ask every time
When Asha logs in with a password, three things happen:
She types her email and password.
The Edme App checks the password.
If it matches, she's in.
A well-built app never keeps your password as plain, readable text. It keeps a scrambled version that can be used to check a password you type, but can't be turned back into the original. That's also why "Forgot password" sends you a reset link instead of telling you your old password: the app genuinely doesn't have it.
Why she doesn't log in again for every lesson
Asha opens one lesson, then another, then a test. She doesn't type her password each time. After one successful login, the app gives her phone a temporary pass. This is called a session.
It's like the wristband you get at a concert or a college fest. You show your ticket once at the gate, they put a band on your wrist, and after that you walk around freely until the event ends.
On a website, the browser keeps this pass in a small piece of saved data called a cookie. The Edme App on her phone stores something very similar. Either way, it lets the app recognise her on every screen without asking again.
Tapping "Log out", clearing your browser data, or the pass simply expiring after some time all throw the wristband away. The next time, the app asks for proof again.
Keep this in mind for the rest of the post: whichever way Asha logs in (password, Google or passkey), the login step only proves who she is. The session is what keeps her logged in afterwards.
3. What happens when you tap "Continue with Google"
The Edme App's login screen has a button that says Continue with Google. If Asha taps it, she doesn't need to make a new password for the Edme App at all. Her Google account does the job.
Here's what happens in those two or three seconds:
The Edme App sends Asha over to Google.
Google checks that it's her. She's usually already signed into Google on her phone, so all she does is pick her account.
Google hands the Edme App a signed note that says, in effect: "This is Asha's Google account, and we've checked it."
The Edme App checks that the note really came from Google and was meant for the Edme App, not some other app.
The Edme App starts its own session for her, the wristband from the last section.
sequenceDiagram
participant A as Asha
participant E as Edme App
participant G as Google
A->>E: Taps Continue with Google
E->>G: Please confirm who this is
G->>A: Choose your account
A->>G: Picks her account
G-->>E: Signed note: this is Asha
E->>E: Checks the note is genuine
E-->>A: Opens her Edme accountGoogle vouches for Asha. The Edme App checks Google's note and then starts its own session.
It only receives Google's note. Your Google password stays between you and Google.
The rulebook for writing and checking that note has a name: OpenID Connect, or OIDC. You don't need the details. Just remember that it's the standard way one service tells another, "Yes, this person is who they say they are."
"Continue with Google" only tells the Edme App who you are. Reading your calendar needs a separate permission, which Google will ask you about on its own screen. That's the next section.
4. OAuth: letting an app use a little of your Google data
Asha wants the Edme App to look at her calendar and suggest study slots around her classes and coaching. For that, the app needs to read information that lives with Google.
The bad old way would be to give the Edme App her Google password. That's like handing a friend the keys to your whole house just so they can water one plant. They could open every room.
OAuth is the standard way for you to give one app permission to do a specific thing with your account at another service, without ever sharing your password.
Connecting Google Calendar
When Asha taps Connect Google Calendar in the Edme App, Google shows her its own screen, something like:
Edme App wants to: See your calendar events. [Cancel] [Allow]
If she taps Allow, Google gives the Edme App an access token. Think of it as a limited pass, like a hostel visitor slip that lets someone into the common room and nowhere else. Every time the Edme App asks Google for her calendar, it shows this pass, and Google checks it before answering.
flowchart TD
A[Edme App asks to read the calendar] --> B[Google shows Asha the permission screen]
B --> C{Does Asha allow it?}
C -->|No| D[Nothing is shared]
C -->|Yes| E[Edme App gets an access token]
E --> F[Edme App asks Google for calendar events and shows the token]
F --> G[Google checks the token and sends only what was allowed]No permission, no data. With permission, the token works only for what Asha agreed to.
The pass only covers what you agreed to
A token that lets the Edme App read calendar events can't read her Gmail, can't see her photos, and can't delete her events. This limit is called the scope of the permission. Always read that Google screen before tapping Allow.
Taking the permission back
Asha can remove the Edme App's calendar access any time from her Google Account settings. Under Security there's a list of third-party apps she has connected. Note that logging out of the Edme App does not remove this permission. They're two separate switches.
Google sign-in vs OAuth, side by side
These two get mixed up all the time because they use the same Google screens. Here's the difference:
Continue with Google (OIDC) | Connect Google Calendar (OAuth) | |
|---|---|---|
Question it answers | Who are you? | What may this app do with your data? |
What the app gets | A signed note saying who you are | A limited pass (access token) for specific data |
Example | Logging into the Edme App | The Edme App reading your calendar |
The names appear together for a reason: OpenID Connect is built on top of OAuth 2.0. One adds "who you are" on top of the other's "what you allowed".
5. Web authentication with passkeys
Passwords have two big problems. People forget them, so they reuse the same one everywhere. And people get tricked into typing them on fake websites. Passkeys fix both problems. They're the newest way to log in, and it's worth understanding them properly, because you'll see them on more and more apps.
What a passkey is
A passkey is a login that lives on your phone (or in your Google or Apple account) instead of in your head. You never see it and you never type it. You unlock it with the same thing you use to unlock your phone: your fingerprint, your face, or your screen PIN.
From Asha's side, logging in with a passkey looks like this: tap Sign in with passkey, touch the fingerprint sensor, done. No password, no OTP to wait for.
The two keys behind it
Every passkey is actually a pair of digital keys. They are long strings of numbers made by the phone. Nobody has to remember them.
The private key stays on Asha's phone. It's used to make proof.
The public key is given to the Edme App. It's used to check that proof.
Here's a way to picture it. Imagine Asha owns a rubber stamp with a pattern nobody else in the world has. She keeps the stamp locked away. She gives the Edme App a photo of what the stamp's mark looks like. Whenever she wants to log in, she stamps a fresh sheet of paper, and the app compares the mark against the photo. The app can check the mark, but nobody can carve a copy of the stamp from the photo.
The digital version is far stronger than a real stamp: it's built on maths that nobody can work backwards from the public key, even with powerful computers.
The private key never leaves your device. The public key is safe for the app to keep. On its own it's useless for logging in, so even if someone stole it from the app, they couldn't get into your account with it.
Creating a passkey
Asha is already logged into the Edme App. She goes to her account settings and taps Create a passkey. Then:
Her phone asks for her fingerprint, to make sure it's really her holding the phone.
Her phone makes a brand-new key pair, just for the Edme App.
The private key is saved safely on the phone (or in her Google Password Manager / iCloud Keychain).
The public key is sent to the Edme App.
The Edme App checks the response and saves the public key against Asha's account.
sequenceDiagram
participant A as Asha
participant P as Her phone
participant E as Edme App
A->>E: Taps Create a passkey
E-->>P: Please make a passkey for edmeapp.ai
P->>A: Touch the fingerprint sensor
A->>P: Touches it
P->>P: Makes a key pair and keeps the private key
P->>E: Sends only the public key
E->>E: Saves it on Asha's accountMaking a passkey: the private key stays on the phone, only the public key travels.
Logging in with the passkey
The next day Asha opens the Edme App and taps Sign in with passkey.
The Edme App sends her phone a fresh, random puzzle. It's a new one every single time.
Her phone asks for her fingerprint.
Once she touches the sensor, the phone uses the private key to sign that exact puzzle. This signed answer is called a digital signature.
The Edme App checks the signature using the public key it saved earlier.
If it checks out, she's in, and the app starts her session.
sequenceDiagram
participant A as Asha
participant P as Her phone
participant E as Edme App
A->>E: Taps Sign in with passkey
E-->>P: Here is a fresh puzzle, sign it
P->>A: Touch the fingerprint sensor
A->>P: Touches it
P->>E: Puzzle signed with the private key
E->>E: Checks the signature with the public key
E-->>A: Logged inLogging in: the phone signs a new puzzle each time and the app checks it.
Why a fresh puzzle each time? Because then an old answer is worthless. Even if someone somehow recorded yesterday's signed puzzle, today's puzzle is different, so replaying it gets them nowhere. It's the same idea as an OTP that changes on every login.
Why a fake website can't steal a passkey
Picture this. Asha gets an SMS: "Your Edme subscription expires today! Renew at edme-app-offer.com". The page looks exactly like the real Edme login screen.
With a password, she might type it in without noticing the address is wrong. Now the scammers have it.
With a passkey, her phone checks the website's address itself, not by looking at the logo. Her passkey was made for edmeapp.ai, so on edme-app-offer.com the phone simply doesn't offer it. There's nothing for her to type and nothing to hand over.
You can be fooled by a fake page. Your phone isn't fooled by a fake address. With a passkey you never hand your secret over, so there's nothing for anyone to trick you out of.
Your fingerprint stays on your phone
Your fingerprint only unlocks the passkey on your own phone, the same way it unlocks your screen. The Edme App never receives your fingerprint, your face scan or your phone PIN. All it gets is the signed puzzle.
What if you lose your phone?
This depends on where the passkey was saved.
Synced passkeys are saved in your Google Password Manager (Android) or iCloud Keychain (iPhone). When you sign into your Google or Apple account on a new phone, they come back with it.
Device-only passkeys, for example on a USB security key, live on that one device. Lose it, and that passkey is gone.
Either way, keep another way into your account: a second passkey, your Google sign-in, or the app's account recovery. That's your backup door.
Anyone who knows your phone PIN can use your passkeys. Keep a screen lock on, and don't share that PIN, even with friends.
So what is WebAuthn?
You might see the word WebAuthn in settings or articles. It's short for Web Authentication.
WebAuthn is the common language a website uses to talk to your browser about passkeys. With it, the website can say "please make a new passkey for me" or "please sign this puzzle". The browser then talks to your phone's fingerprint sensor, face unlock or security key, and passes the answer back. Chrome, Safari, Firefox and Edge all speak this language. Android and iPhone apps use the same standard underneath, so when an app and its website are linked, one passkey can work in both.
The passkey is the key. WebAuthn is how the website asks your browser to use it.
Common mix-ups about passkeys
What people think | What's actually true |
|---|---|
A passkey is my fingerprint. | No. Your fingerprint only unlocks the passkey on your phone. |
The website stores my fingerprint. | No. It stores only a public key, and never sees your fingerprint. |
If the website gets hacked, my passkey is stolen. | Only the public key could be taken, and that can't be used to log in. |
A passkey works only on the phone I made it on. | Usually not. Most passkeys sync through your Google or Apple account. |
Passkeys are just a fancy password. | No. There's no secret you type or share, which is why fake sites can't catch it. |
6. Putting it all together
Here's Asha's morning, with each idea from this post in its place:
She taps Continue with Google. Google sends a signed note, and the Edme App checks it. (Authentication, using OIDC)
She opens her Prelims lesson. The app checks that her account has bought the course. (Authorization)
She moves on to a practice test. No login again, because her wristband is still valid. (Session)
She connects her calendar. Google asks her permission, and the app gets a limited pass. (OAuth)
She creates a passkey. Tomorrow she can log in with just her fingerprint. (Passkey, using WebAuthn)
Each of these does a different job, and a normal app uses all of them together.
Quick summary
Term | Its job in one line |
|---|---|
Authentication | Proves the account is yours. |
Authorization | Decides what you're allowed to open. |
Session | Keeps you logged in after one successful login. |
Google sign-in / OIDC | Lets Google vouch for who you are. |
OAuth | Gives an app a limited pass to some of your data elsewhere. |
Passkey | Logs you in with a key on your phone instead of a password. |
WebAuthn | The language websites use to create and use passkeys through your browser. |
7. Check yourself
Tap a question to see the answer.
1. Asha logs in successfully but can't open the teacher dashboard. Which check stopped her?
Authorization. Her login worked. Her account just doesn't have teacher permission.
2. Does "Continue with Google" let the Edme App read her calendar?
No. Signing in only tells the app who she is. Calendar access needs a separate permission (OAuth).
3. During a passkey login, what does the public key do?
It checks the proof. The phone signs a fresh puzzle with the private key, and the app uses the public key to check that signature.
4. Does the Edme App receive Asha's fingerprint?
No. The fingerprint check happens only on her phone. The app receives the signed puzzle, nothing else.
5. A fake site copies the Edme login page perfectly. Why can't it get Asha's passkey?
Because her phone checks the website address, not the look of the page. Her passkey belongs to edmeapp.ai, so on any other address the phone won't use it.
6. Hackers break into a website and copy everyone's passkey data. Can they log in as those users?
No. The website only ever had public keys. Logging in needs the private key, which never left the users' phones.
Further reading
If you'd like to go deeper, these are the sources this post is based on. The MDN pages are the friendliest place to start.