How OAuth Lets You "Sign in With Google"

The short answer

Quick answer: OAuth 2.0 lets you give an application limited access to your account on another service without giving it your password. The app sends you to the provider (such as Google), where you log in and approve the request. The provider sends you back to the app with a short-lived authorisation code, which the app exchanges, behind the scenes, for an access token. The app uses that token to call the provider's API on your behalf. "Sign in with Google" adds OpenID Connect, a layer on top of OAuth that also returns an ID token saying who you are, which is what makes it a login.

The problem OAuth solved

Before OAuth, an app that wanted to import your contacts would ask for your email password. That was bad in every way:

• The app saw and often stored your real password.
• It had full access to your account, not just contacts.
• The only way to cut it off was to change your password, which broke everything else too.

OAuth replaced this with delegated access: a token that is limited in scope, limited in time, and revocable by itself.

A hotel key card is a good analogy. The front desk checks your identity and gives you a card that opens your room and the gym, for the length of your stay. It does not give you the master key, and it can be cancelled without changing the locks.

The four roles

RFC 6749 defines four parties:

The authorisation code flow

This is the flow used by web, mobile and single-page apps. PKCE, defined in RFC 7636, is part of it.

1. The app prepares. It generates a random secret called the code verifier, and a hash of it called the code challenge. It also generates a random state value.

2. The app redirects you to the provider:

https://accounts.example.com/authorize
  ?response_type=code
  &client_id=abc123
  &redirect_uri=https://app.example.org/callback
  &scope=openid email calendar.readonly
  &state=xyz789
  &code_challenge=E9Melhoa2Ow...
  &code_challenge_method=S256

3. You log in at the provider. The app never sees your password. If you are already signed in, this step is skipped.

4. You see a consent screen. "This app wants to: view your email address, view your calendar." You approve.

5. The provider redirects you back to the app with a one-time code:

https://app.example.org/callback?code=SplxlOBe...&state=xyz789

The app checks that state matches what it sent.

6. The app exchanges the code for tokens. This is a direct server-to-server request, not through the browser. It sends the code, its client credentials, and the original code verifier.

7. The provider checks everything and returns:

{
  "access_token": "ya29.a0Af...",
  "expires_in": 3600,
  "refresh_token": "1//0gdf...",
  "id_token": "eyJhbGciOiJSUzI1NiIs..."
}

8. The app calls the API with the access token:

GET /calendar/v3/events
Authorization: Bearer ya29.a0Af...

Why the extra step with a code?

Why not return the token in the redirect?

Because the redirect passes through your browser. URLs end up in history, logs and referrer headers, and other software on the device may see them. The code is useless on its own: it is single-use, expires in seconds, and can only be exchanged by a party that also holds the right secret.

PKCE closes the remaining gap. Even if someone intercepts the code, they cannot exchange it, because they do not have the code verifier whose hash was sent in step 2. PKCE was created for mobile and browser apps, which cannot keep a client secret, and is now recommended for every client.

State protects against a different trick: an attacker injecting their own code into your session.

The tokens

Scopes define what an access token permits, such as calendar.readonly. A well-behaved app asks for the minimum it needs.

Access tokens are bearer tokens: whoever holds one can use it. That is why they are short-lived and must only be sent over HTTPS. See how HTTPS works.

OAuth is authorisation. OpenID Connect is login.

Plain OAuth answers "may this app access that data?" It does not, by itself, tell the app who you are. An access token is meant for the API, not for the app to interpret.

OpenID Connect (OIDC) adds identity. When the app requests the openid scope, the provider also returns an ID token: a signed JWT with claims about you.

{
  "iss": "https://accounts.example.com",
  "sub": "110169484474386276334",
  "aud": "abc123",
  "email": "[email protected]",
  "exp": 1760000000
}

The app verifies the signature, checks that the issuer and audience are correct, and then knows who has signed in. It usually then creates its own session for you. See JWT vs sessions.

So "Sign in with Google" is OpenID Connect running on top of OAuth 2.0.

Why apps offer it

For users

• No new password to create and remember.
• You can see and revoke each app's access from your account settings.
• The app inherits the provider's security, including two-factor authentication. See how two-factor authentication works.

For developers

• No passwords to store. See how passwords should be stored for what that saves you from.
• Quicker sign-up.

The costs

• If the provider account is compromised or locked, so is access to every connected app.
• The provider learns which apps you use.
• Your app depends on the provider being available.

Other flows

Current best practice, gathered in the OAuth 2.1 draft and summarised at oauth.net, drops the last two and requires PKCE.

Security mistakes to avoid

• Loose redirect URI matching. The provider must only redirect to exact, pre-registered addresses. Otherwise codes can be sent to an attacker.
• Skipping the state check.
• Not using PKCE.
• Not validating the ID token: its signature, issuer, audience and expiry.
• Using an access token as proof of identity. A token issued to a different app may be replayed. Use the ID token for login.
• Asking for too many scopes.
• Storing tokens where page scripts can read them.
• Exposing a client secret in a mobile app or front-end code.

Use a well-maintained library or an identity service. The flows have many subtle details.

Frequently asked questions

What is the difference between OAuth and OpenID Connect?

OAuth 2.0 is for granting an app access to resources. OpenID Connect is built on top of it and adds a standard way to verify the user's identity.

Does the app see my Google password?

No. You enter it only on the provider's own page. The app receives tokens.

What is PKCE?

Proof Key for Code Exchange. The app proves, when exchanging the authorisation code, that it is the same app that started the flow, which defeats interception of the code.

What is the difference between an access token and a refresh token?

An access token is short-lived and is sent to APIs. A refresh token is longer-lived and is used only to obtain new access tokens.

Conclusion

OAuth lets you hand an application a limited, revocable key in place of your password. The redirect, the code, the exchange and PKCE each exist to keep tokens away from places where they could leak. OpenID Connect adds the identity layer that turns access delegation into "sign in with". Together they mean a new app never needs to know your password at all.

Related articles

• JWT vs Sessions: How Authentication Really Works
• How HTTPS Keeps Your Data Safe (TLS Handshake Explained)
• How Two-Factor Authentication Codes Are Generated
• How Passwords Should Be Stored (Hashing and Salting)

Sources and further reading

• RFC 6749: The OAuth 2.0 Authorization Framework
• RFC 7636: Proof Key for Code Exchange (PKCE)
• OAuth 2.0