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 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.
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.
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!