This is the safest, but also the most complex, grant flow. This grant flow requires that the user interacts with the authorization server using a web browser for authentication and giving consent to the client application, as illustrated by the following diagram:

Figure 11.1: OAuth 2.0 – authorization code grant flow Here's what's going on in this diagram:

The client application initiates the grant flow by sending the user to the authorization server in the web browser.

The authorization server will authenticate the user and ask for the user's consent.

The authorization server will redirect the user back to the client application with an authorization code. The authorization server will use a redirect URI specified by the client in step 1 to know where to send the authorization code. Since the authorization code is passed back to the client application using the web browser, that is, to an unsecure environment where malicious JavaScript code can potentially pick up the authorization code, it is only allowed to be used once and only during a short time period.

To exchange the authorization code for an access token, the client application is expected to call the authorization server again. The client application must present its client ID and client secret together with the authorization code for the authorization server. Since the client secret is sensitive and must be protected, this call must be executed from server-side code.

The authorization server issues an access token and sends it back to the client application. The authorization server can also, optionally, issue and return a refresh token.

Using the access token, the client can send a request to the protected API exposed by the resource server.

The resource server validates the access token and serves the request in the event of a successful validation. Steps 6 and 7 can be repeated as long as the access token is valid. When the lifetime of the access token has expired, the client can use their refresh token to acquire a new access token.