You have already studied how this application handles its own passwords in user-credentials and two-factor-authentication. Token and session vocabulary from session-jwt-security is useful background; key terms are restated inline here, so that lesson is not a hard prerequisite. This lesson looks at the other common way users log in: federated login, the "Login with Google", "Sign in with Apple", or "Continue with GitHub" buttons you see everywhere.
Prerequisites: session-jwt-security, cross-site-request-forgery, unvalidated-redirects, and encoding-encryption-hashing. Each supplies vocabulary used directly in this lesson: session-jwt-security explains what a token is and how a session is maintained after login; cross-site-request-forgery explains the role of the state parameter in the OAuth callback; unvalidated-redirects explains why the redirect_uri must be allowlisted; and encoding-encryption-hashing covers Base64, which NovaCart's pitfall exploits directly.
The core idea: delegate authentication. Instead of storing your password, the application asks a third party you already trust — an identity provider (IdP) such as Google — to authenticate you and then vouch for you. The application (called the relying party or client) receives a verifiable assertion that "this user logged in successfully" and never sees the password at all.
Why this is usually a good thing. Every application that stores passwords inherits a permanent burden: hash them correctly, defend the database, handle resets, and survive credential-stuffing. Federation hands that burden to an organization whose whole business specializes in it.
Why it still goes wrong. Delegation introduces a new set of moving parts — redirects, codes, tokens, and a handshake between three parties. Mishandle any one of them and you get a fresh class of bugs: stolen authorization codes, forged callbacks, leaked tokens, and account takeover. Worse, even a flawless handshake can be undermined by what the application does after login — as NovaCart's "Login with Google" account will show you, where the account's fallback password is nothing more than the user's email address in disguise.
In this lesson you will:
- Walk the OAuth 2.0 authorization-code flow end to end and see why tokens are exchanged on a back channel.
- Separate OAuth (authorization) from OpenID Connect (authentication) — the access token versus the ID token.
- Learn what the **
redirect_uriandstate** parameters defend against. - Inspect a real OAuth request in your browser's DevTools.
- See why a predictable, derived credential quietly defeats the whole point of federation.
Estimated time: 25 to 35 minutes.
Click Continue when you are ready.