Chapter 13. User authentication with OAuth 2.0

This chapter explains why OAuth 2.0 is a delegation framework for authorization, not an authentication protocol, even though it often appears in login flows. It distinguishes authentication (proving who the user is and whether they are present) from authorization (granting a client scoped access), and cautions that conflating the two leads to insecure designs. OAuth can, however, serve as a key ingredient within a broader “recipe” for authentication, where additional components supply identity assertions and context that OAuth alone does not provide.

To build authentication on top of OAuth, the chapter remaps roles: the client becomes the relying party (RP) and the authorization server plus protected resource act together as an identity provider (IdP). The user authorizes release of identity data, and the RP receives two artifacts: an access token for APIs and a separate ID token that conveys who authenticated, for whom, and under what conditions. The text catalogs common pitfalls when treating plain OAuth as authentication—such as assuming access tokens prove login, relying on API access as proof of user presence, token injection, missing audience restrictions, tampered user data, and provider-specific variations—and outlines mitigations including using the authorization code flow with state/nonce, validating signed tokens with correct audience and lifetimes, and preferring a standardized identity layer.

OpenID Connect provides that standardized layer by defining a signed ID token (a JWT with issuer, subject, audience, timestamps, and optional authentication context) delivered alongside the OAuth access token, plus a UserInfo endpoint gated by well-known scopes for profile attributes. It adds dynamic discovery and client registration so RPs can interoperate with many IdPs, remains compatible with plain OAuth, and offers advanced options like JWT-based client authentication, signed/encrypted responses, request objects, hybrid flows, and session management. The chapter closes by walking through a minimal implementation: issuing and validating ID tokens, exposing a UserInfo endpoint, and fetching/displaying user attributes—demonstrating how a few targeted additions transform an OAuth deployment into a robust, interoperable login system.

Attempting to make an authentication protocol out of OAuth, and failing

Making an authentication protocol out of OAuth, more successfully

Components of an OAuth-based authentication and identity protocol

A NASCAR-style identity provider selector

WebFinger transforms an email address into a URL

The client page showing a logged-in user

The client showing a successful login and fetch of user information

FAQ