Explore our platform and learn how it can help your application shine.
Learn about modern authentication techniques and best practices.
Learn about access management practices and technologies.
Learn to manage user accounts and access at scale.
Understand multi-tenancy, a foundation of shared computing.
Learn how to design and build successful SaaS applications.
Understand what is required to provide an enterprise-ready product.
Understand the uses and benefits of Attribute-Based Access Control.
Learn how Single Sign On (SSO) can improve security and UX.
Learn about OpenID Connect, an open authentication protocol.
Learn about SAML, a popular SSO protocol.
Learn about our history, our team, and our mission.
OAuth 2.0 is an open-standard authorization framework that allows services or servers to provide delegated and regulated access to their assets. OAuth grant types are methods for getting tokens to make requests to a resource server. The grant type you choose depends on the security level, client application type, and other conditions. The most common grant type is the Authorization Code Grant. In this type, the authorization server returns a single-use authorization code to the client, which is then exchanged for an access token.
Here are some OAuth grant types that we’ll be covering extensively in this article:
Resource owner password credentials: This grant type is for highly trusted apps where resource owners share their credentials directly with the app.
Old Web Access Management (WAM) policies were rigid and not really suitable for companies that scaled up fast or had unpredictable user influxes. OAuth essentially solves the problem by decoupling decisions related to authorization from the authentication process. This helps achieve coarse grained authorization, enabling controlled and regulated access to specific APIs while building apps.
OAuth is also great because it can be integrated seamlessly into identity deprovisioning workflows, which are a crucial part of any B2B setup today. You may also want to keep some things in mind while implementing OAuth 2.0. It isn’t compatible with the older OAuth 1.0, nor is it an authentication protocol. This means that interoperability issues may arise while trying to integrate it.
Here is a quick rundown of the main actors participating in the OAuth flow.
I wish to refresh your memory and mention OpenID Connect (OIDC). This is basically an identity layer that sits atop OAuth2 to overcome it’s authorization-centric nature and make it a true solution for B2B applications and platforms. OIDC enhances OAuth 2.0 with a new signed id_token for the client and a UserInfo endpoint to fetch user attributes.
Read More: OIDC vs SAML
Now that we have covered the basics of OAuth 2.0 and OIDC, we need to take a closer look at OAuth grant types. The grant type basically refers to the way your app gets the access token. OAuth 2.0 offers different types of grant types, with extensions also capable of defining new grant types. There is no clear cut winner when it comes to OAuth 2.0 grant types because every use case is different.
The flow between the OAuth service and client application is kickstarted via a series of browser-based HTTP requests. Once the user consents to the access request, an authorization code is granted to the client application, which communicates with the OAuth service to get an “access token.” This token is very crucial, as it allows the making of API calls to fetch the required user data.
Following this exchange, all communications (server-to-server) are performed over safe back-channels, which are established during registration with the OAuth service (also, a client_secret is generated at this time, which the client application uses to authenticate itself while sending server-to-server requests). The end-user is not exposed to these communications in any way or form.
Since most sensitive data, like the access token and user data is not sent via the browser, this grant type is arguably the best for server-side apps.
The Implicit Grant Type was designed for applications where the token is returned directly to the browser without the need for an intermediate server step. It’s considered a simpler flow than the Authorization Code, but at the cost of lesser security.
The Implicit Grant Flow:
This grant type is less recommended nowadays due to potential security vulnerabilities, especially in the modern web application environment. The absence of client authentication and the exposure of the token in the URL are primary concerns.
Proof Key for Code Exchange is a security-centric OAuth grant type. The main concept behind PKCE is proof of possession. This basically means that the client app needs to prove to the authorization server that the authorization code is authentic, before getting an access token from it. The PKCE flow includes a code verifier and a code challenge, along with a code challenge method.
This is how the Proof Key for Code Exchange (PKCE) flow looks:
The Device Code grant type is used by input-constrained devices (think IoT) in the flow to exchange a previously obtained device code for an access token.
The device authorization flow goes as follows:
The Device Code grant type value is: urn:ietf:params:oauth:grant-type:device_code
The client also has the option of requesting an Access Token using only its credentials (or other supported types of authentication if available). This becomes extremely relevant when the client is requesting access to the protected resources under its direct control, or those of another resource owner that have been previously arranged with the authorization server.
As the name suggests, Refresh Tokens are essentially user credentials that help obtain Access Tokens. These tokens are given by the authorization server and are utilized to obtain new access tokens when the old one expires or turns invalid. Refresh Tokens can also be utilized to obtain supplementary access tokens with more dedicated purposes or more limited scope (e.g., where security is crucial).
So how does the Refresh Token Grant flow look? First, the client sends a POST request to the authorization server. The parameters may look like the following:
Once the request is received, the authorization server usually responds with a JSON object that consists of the following properties:
Please note that unlike Access Tokens, Refresh Tokens are meant to be used only with authorization servers. They are never sent to resource servers.
The Resource Owner Password Credentials Grant, or simply the Password Grant, is a flow where the user shares their credentials (username and password) directly with the client application. The client then exchanges these credentials with the authorization server for an access token.
The Resource Owner Password Credentials Flow:
This grant type is considered less safe, as it involves sharing the user’s password directly with the client. Therefore, it’s recommended only for trusted clients or legacy applications where other flows are not feasible. It’s essential to ensure the application keeps the user’s credentials secure and doesn’t misuse them.
Related: Identity Management (IdM) Systems: Explained
Now that we have covered the main OAuth Grant Types and examined their characteristics, it’s also important to know when to use them. One of the first questions you should be asking yourself – Is your client a trusted first-party or a third-party one you don’t really know? This fact alone will essentially dictate the rest of your decision process and guide you towards the right choice/s.
If end-user identification is required for authorization in the resource server, and if the client is either a server-side web app (or a native one) accessed by third party users, using the Authorization Code Grant makes sense. On the other hand, if your resources are being accessed with an authorized machine, with no user permission required, you should seriously consider the Client Credentials Grant.
The Complete Guide to SaaS Multi-Tenant Architecture
Looking to take your User Management to the next level?
Rate this post
5 / 5. 1
No reviews yet