Unlocking the Power of OAuth 2.0: Revolutionizing User Authentication and Authorization
Simplify access control, empower developers, and revolutionize identity management.
You might have come across an application offering a login option through Google, Facebook, or Twitter. This saves the user the task of remembering multiple login credentials. You can provide this Single Sign On (SSO) authentication method to your user through OAuth2.0, which provides both convenience and security.
In this blog, we will explore OAuth2.0, its popularity, working principles, benefits, limitations, and the process of registering an application with Google for OAuth2.0 implementation.
Introduction to OAuth 2.0
OAuth2.0 is the second version of OAuth (Open Authentication). OAuth2.0 is an authorization framework used to secure and manage access to web APIs. It helps to achieve application to gain access to protected resources on behalf of a resource owner, using a third-party authorization server to authenticate the user.
Let’s examine the roles involved in OAuth2.0’s authorization and authentication process.
OAuth 2.0 Roles
OAuth2.0 includes four main roles: the resource owner, the client, the resource server, and the authorization server.
- Resource owner: The resource owner is the user who owns the data that the client wishes to access. They grant the application or client permission to utilize their data, such as photos on a social media site or files on a cloud storage provider.
- Client: The client is the application that wants to access the user’s data. It can be a web or mobile application that requires data to complete certain tasks. For example, an application that tracks and manages users’ activity and sends emails containing that data to users. To carry out these tasks, the application requires access to specific data.
- Resource server: A resource server is a server that protects the user resource from unauthorized users. It validates and accepts the access token from the application, and after successful validation, it returns the resource to the client.
- Authorization server: The authorization server is the server that authenticates user credentials, and after verifying the user, it grants access to the client. The authorization server also issues the access token to the client. Using this access token, the client will verify the user and grant access to the required resource.
In OAuth2.0, after the user authenticates by the authorization server, the authorization server gives the grant to the user. OAuth2.0 uses a different type of grant to obtain the access token. Let’s learn about them in detail.
Grant Type in OAuth2.0
In OAuth2.0, a grant type is used to acquire an access token for authentication and authorization purposes when accessing a protected resource on a server. OAuth2.0 offers various grant types tailored for different scenarios and use cases. Some popular grant types include:
- Authorization Code Grant: This is the most common grant in OAuth2.0. During this process, the application redirects the user to the authorization server’s login page. The user uses their credentials to log in to the authorization server, and the authorization server grants access to the client application. The authorization server then redirects the user to an application with an authorization code.
- Implicit Grant: Normally, the authorization server sends the access token directly to the client application. However, the authorization server does not send the access token directly to the client in implicit grant flow. Still, it may return the access token as a parameter in the URI or as a response to a form post. Sending the access token in the URI parameter is unsafe because it may lead to security vulnerability.
- Authorization Code Grant with Proof Key for Code Exchange (PKCE): This authorization flow is like the authorization code grant but with additional steps that make it more secure for mobile/native apps and SPAs.
- Resource Owner Credentials Grant Type: This grant requires the client first to acquire the resource owner’s credentials, which are passed to the authorization server, therefore, limited to clients that are completely trusted. It has the advantage that no redirect to the Authorization server is involved, so it is applicable when a redirect is infeasible.
- Client Credentials Grant Type: This grant is used for non-interactive applications, e.g., automated processes, microservices, etc.
- Device Authorization Flow: This grant is used for input-constrained devices like smart TV.
- Refresh Token Grant: This grant type is used to obtain a new access token using a refresh token, a long-lived token used to obtain new access tokens without requiring the user to re-authenticate.
How Does OAuth2.0 Work?
OAuth2.0 can involve several grant types or flows, such as the authorization code grant, implicit grant, and client credentials grant, each with its own specific use case and steps in the authorization process. The general workflow involves the following steps:
- The application requests authorization to access service resources from the user.
- The application supplies the client ID and the secret as identification. It also provides the scopes and an endpoint URI (redirect URI) to send the access token or the authorization code.
- The authorization server authenticates the client and verifies that the requested scopes are permitted. The authorization server issues an access token to the application, and authorization is complete.
- The application requests the resource from the resource server and presents the access token for authentication.
- The resource server validates the access token; if it is valid, it serves the resource to the application.
Application Registration
Before using OAuth in an application, you should register your application with the service. This is done through a registration form in the developer or API portion of the service’s website, where you will provide the information like:
⦁ Application Name
⦁ Application Website
⦁ Redirect URL or callback URL
Let’s see an example of application registration on Google to obtain the client ID and client secret for your application.
Registering application on Google
To use OAuth2.0 in your application, you need an OAuth2.0 client ID, which your application uses when requesting an OAuth 2.0 access token.
To create an OAuth2.0 client ID in Google:
- Go to the Google Cloud Platform Console (https://console.cloud.google.com/)
- Create a new project for your application
- Open the console on the left side menu and select APIs & services > OAuth consent screen.
- Select the user type Internal or External
- Fill in the application data like the application name and email, upload the app logo, app domain, and save it.
- You can add the scope of the required data. Adding scope expresses the permissions you request users authorize for your application. It allows your project to access specific types of private user data like auth/userinfo.profile and auth/userinfo.email from their Google account.
- If your application status is “Testing, " only test users can log in to your application using Google OAuth. You can add up to 100 test users in your application.
- After creating an application, go to the credential tab to create a client ID
- To create a client ID, click on CREATE CREDENTIALS > OAuth client ID
- Select the Application Type. You also need to define which type of application will use this client ID because a single client ID is used to identify a single application to Google OAuth servers. You can create multiple client IDs for the same application. Google allows users to create up to 100 Client IDs.
- Fill in required data like authorized JavaScript origin, authorized redirect URIs, and create client ID and client secret.
- Using the given client ID and client secret, Google identifies the application and redirects the user to the login page. After authentication, it’ll give an access token to the application.
Different authorization servers like Facebook, Twitter, GitHub, and LinkedIn have different processes to register applications and create client IDs and secrets.
In a single application, you can use multiple authorization servers like Google, Facebook, GitHub, etc.
Implementing OAuth2.0 in different languages
The following link contains different articles and blogs for different languages to implement OAuth2.0 in the application.
Java: https://spring.io/guides/tutorials/spring-boot-oauth2/
Go: https://blog.cloudnativefolks.org/oauth-20-implementation-in-golang
Limitations and Potential Security Vulnerabilities in OAuth2.0
OAuth2.0 is a robust security protocol, but like any other technology, it has its limitations and potential security vulnerabilities. Here are some of the most common issues associated with OAuth2.0:
- Stealing OAuth token via redirect Uri: This is the most popular OAuth-based vulnerability where the configuration of the OAuth service itself enables attackers to steal the authorization code or access token associated with it. Using this access token, the attacker may be able to access the victim’s private data.
- Reusability of an OAuth access token: Sometimes, previously used OAuth token does not expire with an immediate effect post-log-out of the account. In such a case, there is a possibility that it can be reused to log in with the previous access token.
- Host header injection at access token request: It’s not a common vulnerability. Sometimes, testing whether the host is being validated on the server side while carrying the access token is good. If it’s not, then the token can be redirected to another malicious host.
- Flawed scope validation: When the user logs in to the authorization server, they will show the list of data that the client application wants to access. Sometimes an application gathers more information than the user wants to share.
Wrapping up
There are some limitations in OAuth2.0, but overall, OAuth2.0 is a popular and widely adopted security protocol that provides several advantages over other security protocols.
Its simplicity, granularity, third-party authentication, wide adoption, and support for mobile and web-based applications make it an excellent choice for enabling secure access to web-based applications and APIs.
For more updates on the latest tools and technologies, follow the Simform Engineering blog.
