Authorization Code Flow

Overview

• Called Three-legged because this flow enables checking the identity of the three involved actors i.e. OAuth Server, Resource Owner, and Client
• This flow is usually used by server-side applications which the client secret and tokens can be securely stored and protected
• This flow is not recommended for client-side applications where client secret and tokens cannot be securely stored

Access Flow

1. Get the Authorization Code at the authorization endpoint
2. Get the Token at the token endpoint
3. Use the Access Token to access the resource at the resource endpoint

Authorization Endpoint Flow

1. Resource owner uses the client to access the resource
2. Client sends request to OAuth server asking for Authorization Code at the authorization endpoint
3. OAuth server shows the login page to the Resource Owner on the browser
4. Resource owner enters username and password and submit to the OAuth Server to validate
5. OAuth server show consent page to the Resource Owner with the requested resources
6. Resource Owner provides consent back to the OAuth server
7. OAuth Server sends HTTP response with status 302 and the Authorization Code back to the browser so it redirects back to the client. Client finally gets the Authorization Code.

Token Endpoint Flow

1. Client sends request to OAuth server asking for Access Token at the token endpoint with:
   • Client Credential (ClientID:ClientSecret) so OAuth server knows which client it is interacting with.
   • grant_type=authorization_code
   • Authorization Code got from previous flow
2. OAuth Server validate the Authorization Code (usually has a short validity) and send back JSON back to the client with Access Token and Refresh Token

Resource Endpoint Flow

1. Client sends request to Resource Server at the resource endpoint with Access Token
2. Resource Server verify Access Token with the OAuth Server whether client can access the resource
3. Resource Server responses back to the client with the requested resource

Refresh Flow

• Used when Access Token expires (specified in expires_in field)
• Refresh token has longer validity than the Access Token. (Validity not sent back to the client)
• Refresh token is used to minimize the time requiring resource owner to re-login.

To get a new access token with refresh token, here are steps:

1. Client sends request to the OAuth server at the token endpoint with grant_type=refresh_token
2. OAuth Server sends back the new access token and the new refresh token
3. Client uses the new access token to request for resources