OAuth: a quick overview - Part II

The first part of the content introduces OAuth, its purpose, roles, grant types, bearer tokens and JWT, and a little of the OAuth 2.1 project. Next, I will demonstrate how the authorization flows (grant types) work.

Client Credentials

Client Credentials is used when clients (applications) request a token to access their own resources on their behalf, not on behalf of the user. These clients are usually machine-to-machine (M2M) applications, such as CLIs, daemons, or services running on the backend. Therefore, this flow should only be used for trusted clients. Here is how it works.

1. Application (m2m app) sends request (/oauth/token) to OAuth server with Client ID + Client Secret.
2. OAuth Server validates Client ID + Client Secret.
3. OAuth Server responds with the access token.
4. Application uses the token to call the API.
5. API responds with requested data.

Authorization Code + PKCE

This flow is used to obtain an access token via an authorization code. Here we are talking about both trusted applications and public applications, be they web, mobile or native. 

Unlike Client Credentials, in this case the resource owner is an end user, so the application needs to open the browser to start the flow. Since it involves public applications, some additional security measures are required. This is why we have the Proof Key for Code Exchange or PKCE (RFC 7636). This is an extension of the Authorization Code flow that prevents injection and CSRF attacks by creating a “combination” with each authorization request, and together with this combination and the authorization code, requests an access token. See the image below.

1. User logs into the application.
2. Application creates a code_verifier and generates the code_challenge from it.
3. Application sends request (/authorize) to OAuth Server using code_challenge.
4. OAuth Server redirects the user to log in and requests authorization.
5. User authenticates/provides consent.
6. OAuth Server saves code_challange and redirects the user to the application with an authorization code.
7. Application sends request (/oauth/token) with authorization code + code_verifier to the OAuth Server.
8. OAuth Server validates code_challenge (sent in step 3) and code_verifier (sent in step 7).
9. OAuth Server responds with the access token.
10. Application uses the token to call the API.
11. API responds with requested data

The protocol recommends using Client Credentials for M2M applications and Authorization Code + PKCE for other types of applications. As I explained in part I, my intention with these two articles was to provide a quick overview of OAuth. I hope to have succeeded in it. Thanks again to everyone who has born with me up to here. Farewell!