Introduction to the OAuth 2.0 Authorization Framework
What is OAuth 2.0?⌗
The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service or allowing the third-party application to obtain access on its behalf. 1
OAuth defines a set of terminologies:⌗
- Resource owner: an entity that is capable of granting access to a protected resource.
- Resource server: server hosting the protected resources and is capable of respoding to requests for the resources using access tokens,
- Client: an application making protected resource requests on behalf of the resource owner with its authoriztion.
- Authorization server: the server issuing access tokens to the client after a successful authentication of the resource owner and obtaining authorization.
A look
+--------+ +---------------+
| |--(A)- Authorization Request ->| Resource |
| | | Owner |
| |<-(B)-- Authorization Grant ---| |
| | +---------------+
| |
| | +---------------+
| |--(C)-- Authorization Grant -->| Authorization |
| Client | | Server |
| |<-(D)----- Access Token -------| |
| | +---------------+
| |
| | +---------------+
| |--(E)----- Access Token ------>| Resource |
| | | Server |
| |<-(F)--- Protected Resource ---| |
+--------+ +---------------+
Figure 1: Abstract Protocol Flow
Protocol Workflows⌗
Flows (or grants) are ways of retrieving an access token.
OAuth 2.0 authorization framework supports different flows. When deciding which flow to use, you have to choose depending on your use case. In this article, we will not cover how to go about this. Instead, we will have a look at some of the flows that you can explore.
Client Credentials Flow⌗
This is common in machine-to-machine interactions. Your application has control over the resources or the other server with which there is an arrangement for their interaction.
+---------+ +---------------+
| | | |
| |>--(A)- Client Authentication --->| Authorization |
| Client | | Server |
| |<--(B)---- Access Token ---------<| |
| | | |
+---------+ +---------------+
Figure 2: Client Credentials Flow
Authorization Code Flow⌗
Used to obtain both access token and refresh tokens and is optimized for confidential clients. The client must be able to interact with the resource owner’s user-agent (i.e. 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)
Note: The lines illustrating steps (A), (B), and (C) are broken into two parts as they pass through the user-agent.
Figure 3: Authorization Code Flow
Resource Owner Password Flow⌗
Suitable for scenarios where the resource owner has trust with the client i.e. device operating system.
+----------+
| Resource |
| Owner |
| |
+----------+
v
| Resource Owner
(A) Password Credentials
|
v
+---------+ +---------------+
| |>--(B)---- Resource Owner ------->| |
| | Password Credentials | Authorization |
| Client | | Server |
| |<--(C)---- Access Token ---------<| |
| | (w/ Optional Refresh Token) | |
+---------+ +---------------+
Figure 4: Resource Owner Password Credentials Flow
Authorization Code Flow with Proof Key for Code Exchange (PKCE) Flow⌗
This flow builds upon the standard Authorization Code Flow only that it introduces a “code verifier” which is a dynamically created cryptographically random key. A unique code verifier is created for every authorization request, and its transformed value, called “code challenge”, is sent to the authorization server to obtain the authorization code. The authorization code obtained is then sent to the token endpoint with the “code verifier”, and the server compares it with the previously received request code so that it can perform the proof of possession of the “code verifier” by the client.
| Authz Server |
+--------+ | +---------------+ |
| |--(A)- Authorization Request ---->| | |
| | + t(code_verifier), t_m | | Authorization | |
| | | | Endpoint | |
| |<-(B)---- Authorization Code -----| | |
| | | +---------------+ |
| Client | | |
| | | +---------------+ |
| |--(C)-- Access Token Request ---->| | |
| | + code_verifier | | Token | |
| | | | Endpoint | |
| |<-(D)------ Access Token ---------| | |
+--------+ | +---------------+ |
+-------------------+
Figure 5: Abstract Protocol Flow
This workflow was introduced due to the Authorization Code Flow being susceptible to authorization code interception attack.
No comments yet!