OAuth 2.0 Hacking Simplified — Part 1 — Understanding Basics
What is OAuth 2.0?
OAuth is an open-standard authorization protocol or framework that describes how unrelated servers and services can safely allow authenticated access to their assets without actually sharing the initial, related, single logon credential.
Auth0 generates access tokens for API authorization scenarios, in JSON web token (JWT) format. The permissions represented by the access token, in OAuth terms, are known as scopes. When an application authenticates with Auth0, it specifies the scopes it wants. If those scopes are authorized by the user, then the access token will represent these authorized scopes.
It works by delegating user authentication to the service that hosts the user account, and authorizing third-party applications to access the user account.
Where is it used?
OAuth 2 provides authorization flows for web and desktop applications, and mobile devices. Simplest scenario is when you log into a website and it offers log-on using another website’s (Login with Facebook or Google) logon.
For example: the signup page of Medium-
OAuth Entities
Before getting into the core concept, we need to understand different definitions used for different entities in OAuth flow. Let’s understand via an example. A Facebook user wants to sign in into the Medium platform using Facebook. The entities associated with this flow are-
Resource Owner: The resource owner is the user/entity granting access to their protected resource. In our example, it can be user’s data associated with the Facebook account.
Client Application: client application is the application requesting authorization from the resource owner. In our example, this would be the Medium application.
Authorization Server: authorization server is the server issuing access tokens to the client application after successfully authenticating the resource owner and obtaining authorization. In our example, Facebook will be the Authorization server.
Resource Server: The resource server is the server handling authenticated requests after the application has obtained an access token on behalf of the resource owner . In our example, this would be Facebook.
Note: Often the Authorization server and Resource server are the same entity and can be called OAuth provider.
client_id: The client_id is a mandatory parameter containing the public unique identifier of the client application. This value is generated when the client application registers with the OAuth service.
response_type: Determines which kind of response the client application is expecting and, therefore, which flow it wants to initiate. For the authorization code grant type, the value should be code
scope: The scope is the requested level of access the client application is requesting from the resource owner
redirect_uri: The redirect_uri is the URL the user is redirected to after the authorization is complete. This is also known as the “callback URI” or “callback endpoint” . This should match the redirect URL that the user has previously registered with the service.
state: The state parameter stores a unique, random value that is tied to the current session on the client application. According to RFC it is optional but this parameter serves as a form of CSRF Token for the client application by making sure that the request to its /callback endpoint is from the same person who initiated the OAuth flow.
grant_type: The grant_type parameter denotes what the grant type is, and which token is going to be returned.
code: This code is the authorization code received from the authorization server which will be in the query string parameter “code” in this request. This code is used in conjunction with the client_id and client_secret by the client application to fetch an access_token
access_token: The access_token is the token that the client application uses to make API requests on behalf of a resource owner
refresh_token: The refresh_token allows an application to obtain a new access_token without prompting the user
OAuth Flows (Grant Types)
The OAuth grant type determines the exact sequence of steps that are involved in the OAuth process. Flow also affects how the client application communicates with the OAuth providers.
The client application specifies which grant type it wants to use in the initial request it sends to the OAuth service. There are multiple flows available for implementation but which flow to use? This totally depends on the type of client application. (More on it here: https://auth0.com/docs/api-auth/which-oauth-flow-to-use)
Types of flow in OAuth-
- Authorization code grant (aka server side flow)
- Implicit Grant (aka Client side flow)
- Resource credentials grant
- Client credential grant
We will go through the first two as these are the ones which are used mostly in current OAuth implementations.
How does OAuth Work?
Let’s dive into different grant types to understand how OAuth works.
Authorization code grant type
Let’s understand the OAuth flow for Authorization code grant type with a real life example of Hackerrank.
- Authorization request
The client application sends a request to the OAuth service’s endpoint asking for permission to access specific user data.
2. User login and consent
When the authorization server receives the initial request, it will redirect the user to a login page, where they will be prompted to log in to their account with the OAuth provider. They will then be presented with a list of data that the client application wants to access (Like Email, profile picture). This is based on the scopes defined in the authorization request. The user can choose whether or not to consent to this access.
3. Authorization code grant
If the user consents to the requested access, their browser will be redirected to the /callback endpoint that was specified in the redirect_uri parameter of the authorization request. (Remember Step 1)
The resulting GET request will contain the authorization code as a query parameter. This code can be used only once to get the access token.
4. Access token request
Once the client application receives the authorization code, it needs to exchange it for an access token. To do this, it sends a server-to-server POST request to the OAuth service's endpoint.
All communication from this point on takes place in a secure back-channel and, therefore, cannot usually be observed or controlled by an attacker.
5. Access token grant
The OAuth service will validate the access token request. If everything is as expected, the server responds by granting the client application an access token with the requested scope.
6. API call
Now the client application has the access code, it can finally fetch the user’s data from the resource server. Here we are asking the details of certificates achieved by user.
7. Resource grant
The resource server should verify that the token is valid and that it belongs to the current client application. If so, it will respond by sending the requested resource i.e. certificates achieved by user.
And we haven’t completed any so we got nothing in return. But now you are logged in and can navigate the site.
Implicit grant type
The implicit grant type is much simpler. Rather than first obtaining an authorization code and then exchanging it for an access token, the client application receives the access token immediately after the user gives their consent.
- Authorization request
The implicit flow starts in much the same way as the authorization code flow. The only major difference is that the response_type parameter must be set to token.
2. User login and consent
This process is exactly the same as for the authorization code flow.
3. Access token grant
The OAuth service will redirect the user’s browser to the redirect_uri specified in the authorization request. But now it won’t send the query parameter with code as seen previously, it will send access token and other data in the URL itself.
4. API call
Once the client application has successfully extracted the access token from the URL, it can be used to access personal data associated with the user.
5. Resource grant
The resource server verifies that the token is valid. It will send the requested resource i.e. User data.
We will discuss about the vulnerabilities and mitigations in next blog. Hope you learned something new and enjoyed my blog. Stay safe, stay curious.
Thanks for reading!
~Nishith K
Connect with me:
References
- https://portswigger.net/web-security/oauth
- https://auth0.com/docs/protocols/protocol-oauth2
- https://www.digitalocean.com/community/tutorials/an-introduction-to-oauth-2
- https://dev.to/hem/oauth-2-0-flows-explained-in-gifs-2o7a
- https://www.csoonline.com/article/3216404/what-is-oauth-how-the-open-authorization-framework-works.html
