This chapter portrays OAuth 2.0 as a carefully choreographed exchange focused on one central idea: delegated access through tokens. At a high level, every OAuth interaction boils down to two phases—getting a token and using that token—so a client can act on a resource owner’s behalf without ever seeing their credentials. The discussion introduces the system’s moving parts and shows how they coordinate securely using a mix of direct server-to-server calls and browser-mediated redirects, resulting in a practical, flexible, and secure model for authorization.
The chapter then walks through the authorization code grant end to end. A user asks a client to access a protected API; the client redirects the user’s browser to the authorization server with parameters indicating who it is and what access (scopes) it seeks. The user authenticates directly with the authorization server and approves or denies the request; if approved, the server sends the browser back to the client with a one-time authorization code and the original state value. The client validates state, then privately exchanges the code and its own credentials at the token endpoint to obtain an access token (and possibly a refresh token). With the access token in hand, the client calls the protected resource—typically by presenting a Bearer token in the Authorization header—and receives data according to the rights granted.
Finally, the chapter clarifies the roles and building blocks: clients, resource owners, authorization servers, and protected resources; opaque access tokens that the client carries but does not interpret; scopes that constrain what a token can do; and refresh tokens that let clients renew or narrow access without user interaction. It distinguishes back-channel communication (direct HTTP between servers) from front-channel communication (browser redirects that carry parameters), explaining how separating these paths and binding the code to the authenticated client hardens the flow. The result is a sequence of simple steps that, taken together, provide secure, least-privilege, credential-free delegation across diverse applications and APIs.
The authorization code grant in detail
Sending the resource owner to the authorization server to start the process
The resource owner logs in
The resource owner approves the client’s access request
The authorization code is sent back to the client
The client sends the code and its own credentials back to the authorization server
The client receives an access token
The client uses the access token to do things
Major components of the OAuth 2.0 protocol
Using a refresh token
Back-channel communication
Front-channel communication
Parts of a front-channel request and response
FAQ
What are the two main phases of an OAuth 2.0 transaction?Issuing a token (the client obtains an access token from the authorization server) and using the token (the client presents it to the protected resource to access APIs).Who are the four primary actors in OAuth and what are their roles?Client (app requesting access), Resource Owner (entity that grants access, usually the user), Authorization Server (authenticates/authorizes and issues tokens), and Protected Resource (API that validates tokens and serves data).How does the authorization code grant flow work end to end?The client sends the user’s browser to the authorization endpoint with parameters (client_id, scope, redirect_uri, response_type=code, state). The user authenticates and approves. The authorization server redirects back to the client’s redirect_uri with code and state. The client verifies state, then posts the code and its own credentials to the token endpoint to receive an access token (and optionally a refresh token), which it then uses at the protected resource.Why are redirect_uri and state important?redirect_uri tells the authorization server exactly where to send the user back and binds the code to a known callback. state is a client-generated value echoed back by the authorization server to prevent CSRF and help the client correlate the response with its request.What is an access token and how is it used?An access token represents delegated rights granted to the client. The client treats it as an opaque string and typically sends it in the Authorization header (e.g., Bearer) to the protected resource, which validates the token and enforces the associated permissions.What is a scope and how does it limit access?A scope is a string that represents a specific set of permissions at a protected resource. Clients request scopes; resource owners and authorization servers can grant or deny them. Scopes are space-separated and generally additive, limiting the token to just the requested rights.What is a refresh token and when should it be used?A refresh token is issued by the authorization server to let the client obtain new access tokens when one expires or is revoked, without re-engaging the user. It is never sent to the protected resource and can be used to request reduced (down-scoped) access if desired.What is the difference between front-channel and back-channel communication?Front channel uses the user’s browser and HTTP redirects to pass parameters between the client and authorization server; it’s visible to and can be influenced by the browser. Back channel is a direct HTTP call between servers (e.g., token exchange and API calls), allowing client authentication and keeping sensitive data out of the browser.How does the client authenticate when exchanging an authorization code for a token?The client makes a direct POST to the token endpoint including grant_type=authorization_code, the code, and redirect_uri, and authenticates with its client_id and client_secret (e.g., via HTTP Basic). This occurs over the back channel, isolating the request from the browser.How does a protected resource validate a presented token?It extracts the token (e.g., from the Authorization header), checks that it is valid and not expired, and verifies who authorized it and which scopes it carries. Validation can use a shared token store, introspection, or other server-side mechanisms before deciding whether to serve the request.
pro $24.99 per month
access to all Manning books, MEAPs, liveVideos, liveProjects, and audiobooks!
OAuth 2 in Action ebook for free
