An authorization server manages user identities, obtains resource-owner consent, and issues credentials such as authorization codes and access tokens. It works with a client, which requests access, and a resource server, which stores and protects the data. section 7.3
An OAuth authorization flow typically proceeds as follows:
- Receives an authorization request containing the client identifier, callback address, requested flow, and often requested scopes. section 7.3 section 7.4.1
- Authenticates the resource owner and presents the requested access for consent. section 7.3
- Returns an authorization code or, after approval, issues an access token constrained by scope and validity period. section 7.3 section 7.4.1
Job portal accessing employment history
The job portal redirects the user to LinkedIn with a client ID, redirect URI, response type, and requested scope. After login and consent, LinkedIn returns an authorization code; the portal exchanges it for an access token. PKCE adds a verifier so an intercepted code cannot be exchanged by an attacker. section 7.4.1 section 7.4.2
Figure 7.5 OAuth describes flows through which users (resource owners) can authorize applications (clients) to access their data in an API (resource server). Every flow begins with an authorization request, followed by user login and consent and then by an access token grant.
Use the flow diagram to connect the resource owner, client, authorization server, resource server, consent step, and token grant. section 7.3
