In today's world of interconnectedness and web applications, data security and user identity protection are fundamental aspects. Modern security standards like OAuth 2.0 and OpenID Connect have emerged to address these challenges. In this article, we will explore in detail OAuth 2.0-based authorization, and how this protocol works to enhance security in online applications and services.
OAuth 2.0 is a widely adopted authorization protocol that allows users to grant specific permissions to third-party applications without sharing their access credentials. The main advantage of OAuth 2.0 is that users can grant limited access to their data without revealing their passwords, reducing the risk of compromising the security of their accounts.
The typical flow of OAuth 2.0 involves four main roles:
- Resource Owner: The end-user who owns the protected resources and wishes to allow access to those resources to a third-party application. For example, a user of an online service like Twitter or Facebook.
- Client: The third-party application that requests access to the protected resources on behalf of the resource owner. The client can be a web application, a mobile application, or any other type of application that needs to access the resource owner's data.
- Authorization Server: The component that issues access tokens after authenticating the resource owner and authorizing the client. The authorization server verifies the identity of the resource owner and ensures that the client has the proper permissions to access the requested resources.
- Resource Server: The server that hosts the protected resources the client wants to access. The resource server validates the access tokens and provides the requested resources if the authorization is successful.
The process starts when the client requests access to certain protected resources on behalf of the user. The authorization server then authenticates the user and requests their consent to allow access to the client (within the flows, we will see this as the request consent, which is this screen where the user is asked if he wants to accept or deny the request). Once the user grants consent, an access token is issued to the client, which will be used to access the protected resources on behalf of the user.
Now let's take a look at some examples of the flows defined within the OAuth2.0 standard and how they work.
The Authorization Code Flow
The Authorization Code Flow is one of the most common and secure flows in OAuth 2.0. This flow is used when an application needs to access protected resources on behalf of a user. Below is a definition of the Authorization Code flow:
First, the application redirects the user to the authorization server, requesting permissions to access the protected resources. This is usually achieved through a login page where the user needs to authenticate.
Once the user has successfully authenticated, the authorization server presents a consent page to the user, detailing the permissions requested by the application. The user has the option to accept or deny these permissions.
If the user grants the permissions, the authorization server redirects the user back to the application, including an authorization code in the redirection process. This authorization code is a unique and temporary value that will be used to obtain the necessary access tokens.
Next, the application makes a call to the authorization server, sending the authorization code along with its client identifier and client secret (if applicable). This call is made in the background, without direct user interaction.
The authorization server validates the authorization code and verifies the application's identity. If everything is correct, the authorization server responds with an access token and a refresh token. The access token is used to make requests to the protected resources on behalf of the user, while the refresh token is used to obtain a new access token when the previous one expires.
Finally, the application uses the access token to access the protected resources on behalf of the user. This access token is included in requests to the protected resources as proof of authorization.
The Authorization Code flow provides an additional layer of security by not directly sharing the access tokens with the application. Instead, the application only has access to the authorization code, which is single-use and has a limited lifespan. This helps protect the access tokens in case the application is compromised.
The Authorization Code Flow with PKCE
The Authorization Code Flow with Proof Key for Code Exchange (PKCE) is a variant of the Authorization Code flow in OAuth 2.0 that provides an additional layer of security for public or untrusted applications, such as mobile applications.
In this flow, the application generates a secret value called a code verifier and transforms it into a code challenge using a cryptographic algorithm. Then, the application sends this code challenge to the authorization server when requesting the authorization code.
When the authorization server responds with the authorization code, the application must send the original code verifier along with the authorization code when exchanging them for the access token. The authorization server validates that the sent code verifier matches the original code challenge used during the initial request.
The use of PKCE in the Authorization Code flow provides an additional layer of security by preventing an attacker from intercepting and using a fraudulently obtained authorization code. This is particularly useful in mobile applications where secure storage of the client secret is difficult to guarantee.
As mentioned before, here we must take into account an important and differential part of the previous flow and they are:
- Code verifier, that is any random string, also called secret value.
- Code challenge, method that would be the hashing method used on the code verifier.
Code challenge, that is the code verifier with the hashing applied (This method is irreversible).
The Implicit Grant Flow
The Implicit Grant flow is an authorization method used in the OAuth 2.0 protocol. It allows applications to obtain access to protected resources on behalf of the user without the need to exchange confidential client credentials.
In the Implicit Grant flow, the authorization and access token retrieval process takes place in the user's browser, without involving the client server. This makes it a more suitable flow for client applications running in web browsers or mobile applications.
The Implicit Grant flow is characterized by the following steps:
- The client (application) redirects the user to the authorization page of the service provider (authorization server) with a request for access to specific resources.
- The user authenticates their identity on the authorization server.
- The authorization server generates an access token and delivers it directly to the client through the user's browser, using URL fragments or redirections.
- The client extracts the access token from the URL or the redirected response.
- The client can use the access token to make requests for protected resources on behalf of the user to the service provider.
It's important to note that, due to the nature of this flow, the access tokens generated in the Implicit Grant flow have a shorter lifespan and cannot be renewed through a token refresh process. Therefore, it's recommended for use in applications where exposing access tokens is acceptable and access to resources is limited in time.
The Client Credentials Flow
The Client Credential Flow is an authorization flow in OAuth 2.0 that is used to obtain an access token on behalf of an application or client without direct user involvement. This flow is designed for use cases where an application needs to access protected resources on its own behalf, without requiring authorization from a specific user.
In the Client Credential Flow, the authenticated application or client sends its credentials, usually consisting of a client ID and client secret, to the authorization server. These credentials must have been previously registered and authorized by the authorization server. Once the credentials are verified, the authorization server issues a valid access token for the application or client.
This access token can be used to access protected resources such as APIs or web services on behalf of the application or client. There is no user intervention in this process, as the authorization is based on the application's credentials.
The Client Credential Flow is particularly useful in use cases where an application needs to access protected resources programmatically, such as performing automated operations on an API. However, it's important to ensure that the client credentials are kept secure, as compromising them could allow a third party to gain unauthorized access to protected resources.
The Resource Owner Password Credentials Flow
The Resource Owner Password Credentials (ROPC) flow is one of the authentication flows provided by OAuth 2.0. In this flow, a client (such as a mobile application or a desktop client) directly requests the username and password credentials from the resource owner (the end-user) and then sends them to the authorization server to obtain an access token.
Unlike other OAuth 2.0 flows, such as the standard authorization flow, in the ROPC flow, the client directly requests and obtains the user's credentials. This can occur in situations where the client completely trusts the resource owner and there is a direct trust relationship between the client and the end-user.
The ROPC flow is typically used when it is not possible or practical to use other OAuth 2.0 flows, such as the standard authorization flow, such as in applications that cannot open a browser window or on devices with limited input capabilities.
However, caution should be exercised when using the ROPC flow as it involves sharing user credentials with the client and can increase the risk of compromising the security of the credentials. It is recommended to use other OAuth 2.0 flows whenever possible and reserve the ROPC flow only for specific situations where it is required and the associated risks are fully understood.
How to choose the right flow
Conclusion
OAuth 2.0 has become a crucial security standard for modern web applications and services. Its authorization framework provides a robust and flexible solution for granting controlled access to protected resources without compromising user credentials. By leveraging its flows, developers can choose the most suitable approach based on their specific use cases and security requirements.
The OAuth 2.0 protocol offers several benefits, including reduced risk of compromised credentials, granular access control, and improved user experience. With OAuth 2.0, users can grant selective permissions to third-party applications, ensuring that their data remains secure while enabling seamless integration and interoperability across various platforms.
However, it's important to carefully evaluate the choice of the flow to ensure the optimal balance between security and usability. Each flow has its own strengths and considerations, and developers should consider factors such as the nature of the client application, the trust relationship with the resource owner, and the level of security required.
While OAuth 2.0 provides a robust foundation for secure authorization, it is essential to implement the protocol correctly, adhering to best practices and staying informed about potential vulnerabilities and updates in the security landscape. By staying vigilant and following the evolving standards and guidelines, developers can leverage OAuth 2.0 to build secure and user-friendly applications that protect sensitive data and maintain user trust in the digital ecosystem.
