jspωiki
Authorization Code Flow

Overview#

Authorization Code Flow is the OAuth 2.0 Protocol Flow for the Authorization Code Grant Type which would typically be used for website type applications.

Authorization Code Flow is also called 3-legged OAuth and is a relatively high Level Of Assurance.

The authorization Code Grant type is used to obtain both access_tokens and refresh_tokens and is optimized for confidential clients. Since this is a redirection-based flow, the client must be capable of interacting with the Resource Owner's user-agent (typically a web browser) and capable of receiving incoming requests (via redirection) from the Authorization Server.

     +----------+
     | Resource |
     |   Owner  |
     |          |
     +----------+
          ^
          |
         (B)
     +----|-----+          Client Identifier      +---------------+
     |         -+----(A)-- & Redirection URI ---->|               |
     |  User-   |                                 | Authorization |
     |  Agent  -+----(B)-- User authenticates --->|     Server    |
     |          |                                 |               |
     |         -+----(C)-- Authorization Code ---<|               |
     +-|----|---+                                 +---------------+
       |    |                                         ^      v
      (A)  (C)                                        |      |
       |    |                                         |      |
       ^    v                                         |      |
     +---------+                                      |      |
     |         |>---(D)-- Authorization Code ---------'      |
     |  Client |          & Redirection URI                  |
     |         |                                             |
     |         |<---(E)----- Access Token -------------------'
     +---------+       (w/ Optional Refresh Token)
     Figure 3: Authorization Code Flow
Note: The lines illustrating steps (A), (B), and (C) are broken into two parts as they pass through the user-agent.

The flow illustrated in Figure 3 includes the following steps:

(A) Authorization Request#

The OAuth Client initiates the flow by directing the user-agent to the Authorization_endpoint with an Authorization Request wihich includes:

(B) #

The Authorization Server authenticates the Resource Owner (via the user-agent) (Authentication Method is undefined in OAuth 2.0) and establishes whether the Resource Owner grants or denies the OAuth Client's Authorization Request.

(C) Authorization Response#

Assuming the Resource Owner grants access, the Authorization Server redirects the user-agent back to the OAuth Client using the redirect URI provided in the Authorization Request earlier (or the during OAuth 2.0 Client Registration). The URL redirection URI includes an Authorization Code and any local state provided by the OAuth Client earlier.

(D) #

The OAuth Client requests an Access Token from the Authorization Server's token_endpoint by including the Authorization Code received in the previous step. When making the request, the OAuth Client authenticates with the Authorization Server. The OAuth Client includes the redirect URI used to obtain the Authorization Code for verification.

(E) #

The Authorization Server: If validation is successful, the Authorization Server responds back with:

Known in Advance #

Some basic conditions must exist in advance:

Detailed Use case#

1) The Resource Owner accesses the OAuth Client.

2) The OAuth Client constructs the Authorization Request as a URI.

3) The Resource Owner is redirected by the OAuth Client with the Authorization Request to the Authorization_endpoint on the Authorization Server.

4) The Resource Owner Authenticates the Authorization Server.

5) The Resource Owner is then redirected to the Redirect URI of the OAuth Client. Along with the redirection, the Authorization Server sends an Authorization Code, representing the authorization.

6) When the OAuth Client's Redirect URI is accessed, the OAuth Client connects directly (via a HTTP POST) to the Authorization Server and creates Access Token Request

7) If the Authorization Server can accept the Access Token Request values, the Authorization Server sends back an Access Token Response.

Check the OAuth Scopes of your Access Token
It is essential that the OAuth Client check the scope returned from the Access Token request and verify that it contains the necessary scopes. While your application specified (when requesting an authorization Code) what scopes it would like, the user may have chosen to deny access to certain scopes. For example, the user may have chosen to authenticate only, but not to provide access to the other scopes.

8) The OAuth Client can now use the Access Token to request resources from the Resource Server. The Access Token serves as both:

There is no OpenID Connect involved with this operation. This is all part of OAuth 2.0 Protocol
For OpenID Connect the OpenID Connect Authorization Flow MUST include the "openid" OAuth Scope in the and then the Authorization Server returns an id_token along with an Access_token and perhaps a Refresh_token.

More Information#

There might be more information for this subject on one of the following: