An Overview of OAuth Fundamentals and Flows

OAuth2.0 is an open-standard authorization system that was published in 2010, with corporations like Google and Twitter quickly adopting it. It defines how various services may securely access data assets (through authentication) without revealing any credentials. This is sometimes referred to as delegated authorization. This helps with coarse-grained authorization by providing for limited and regulated access to certain APIs while creating apps.

OAuth is particularly advantageous since it can be efficiently included in identity de-provisioning activities, which are now an essential component of every B2B setup.

OAuth flows are essentially OAuth-supported methods for verifying permissions and resource owner information.

There are distinct protocols for various OAuth flows. There are OAuth flows that allow customers to give credentials straight into the application via an OAuth login screen. Some back-end frameworks even help validation without client interaction. Before we go into the many sorts of OAuth flows, let's go through the basics.

OAuth Fundamentals

The OAuth protocol utilizes the following roles:

• Resource Owner — This entity is the one that grants access to the protected asset. Usually, it is the user.
• Resource Server — The Resource Server is the server that holds the resource that the Resource Owner needs access to. It usually exposes an API, and OAuth helps to grant secure access to this API.
• Client — This is an application that requests access to protected resources for the Resource owner using the application.
• Authorization Server — This is the server in charge of collecting credentials from the Resource Owner and determining whether or not they are permitted to access a protected resource. If they are, they give an access token to allow access. This is the main engine that controls the OAuth flow.

OAuth Flow Types

Moving on, how about we dive into the OAuth Flow types you should be aware of before we start everything rolling and dealing with your specific use case/s?

1. Authorization Code Flow

In the Authorization Code Flow, you have to pass along the application’s Client Secret that is exchanged for an authorization code or token. This flow differs from most of the other flows such that it first requires an app to launch the browser to begin the flow.

Use Cases

Server-side web and mobile applications where the source code isn't public.

How does this OAuth Flow work?

1. The application launches a browser and connects the user to the OAuth server.
2. The user sees the authorization popup and gives permission to the app's request.
3. The user is redirected back to the application with an authorization code in the query string.
4. The authorization code is exchanged for an access token by the application.

2. Client Credentials Flow

The Client Credentials Flow permits applications to pass their Client Secret and Client ID to an authorization server to confirm the user and return an authorization token. This occurs with no user intervention.

Use Cases

Machine-to-Machine (M2M) applications (such as daemons, back-end administrations, and CLIs). In these applications, the authorization flow confirms and grants consent in the background without involving the user, because the "user" is frequently a machine or administration task. It does not appear to be appropriate to display a login prompt or to use social logins.

How does this OAuth Flow work?

1. The application authenticates with the OAuth authorization server by sending the Client Secret and Client ID.
2. The authorization server verifies the Client Secret and Client ID and returns an Access Token to the application.
3. The Access Token permits the application to get to the target API with the expected user details.

Resource Owner Password Flow

In this OAuth flow, the users are asked to submit their credentials via a form, which is then sent to the backend and might be retained for future use. Then, an Access Token is generated for the user. Thus, it is important that the application can be completely trusted. Therefore, this flow is generally not recommended.

Use Cases

Highly-trusted applications, where other flows based on redirects cannot be used.

How does this OAuth Flow work?

1. The user clicks on a login option in the application and enters the credentials in the form provided by the application.
2. The application stores the credentials and then passes them on to the authorization server.
3. The authorization server validates the credentials and then returns an Access Token (and an option Refresh Token).
4. The application is then allowed to access the target API with the user information.

Implicit Flow with Form Post

This flow uses OIDC (OpenID Connect) to perform a web sign-in with features such as WS-FED (Web Services Federation) and SAML (Secure Assertion Markup language). OpenID Connect is a straightforward identity layer built on top of the OAuth protocol. It allows Clients to authenticate End-Identity Users based on Authorization Server authentication and access basic profile information about End-Users in an interoperable and REST-like manner.

OpenID Connect may be used by clients of various sorts, including Web-based, mobile, and JavaScript clients, to request and receive information about authenticated sessions and end-users. The standard suite is extensible, allowing participants to use extra capabilities such as identity data encryption, OpenID Provider discovery, and log out as needed.

The front-end is used by the web application to request and receive tokens without the need for additional backend calls or secrets. You do not need to use, maintain, acquire, or secure secrets in your application using this approach.

Use Cases

Applications that would rather not manage secrets locally.

Hybrid Flow

This method is useful for apps that need to securely store Client Secrets. It provides instant access to an ID token while also allowing for the continual retrieval of additional access and refresh tokens.

This is useful for apps that require immediate access to user data but must first complete some processing before being granted access to protected resources for a lengthy period of time.

Use Cases

Apps that require quick access to user data but also need to use this data on a continuous basis.

Device Authorization Flow

You may use this flow to authenticate users without requesting their credentials. This enhances the user experience on mobile devices, where entering credentials might be difficult. These apps can initiate the authorization process and get a token by providing their Client ID to the Device Authorization Flow.

Use Cases

Online apps that operate on input-constrained devices and provide frictionless authentication using credentials saved on the device.

Authorization Code Flow with PKCE

When public clients (such as native and single-page applications) request access tokens, various additional security issues occur that the Authorization Code Flow cannot manage on its own, including the following:

Native applications

• The Client Secrets cannot be safely stored. Decompiling the app reveals the Client Secret, which is app-bound and the same for all users and devices.
• A custom URL scheme (e.g., MyApp://) may be used to record redirection, possibly allowing malicious apps to get an Authorization Code from your Authorization Server.

Single-page applications

• Client Secrets cannot be safely stored since the browser has access to their complete source.

Given these circumstances, OAuth 2.0 includes a version of the Authorization Code Flow that employs a Proof Key for Code Exchange (PKCE).

The PKCE-enhanced Authorization Code Flow provides a secret produced by the calling application that can be confirmed by the authorization server called the Code Verifier. Furthermore, the caller app generates a Code Verifier transform value called the Code Challenge and delivers it over HTTPS to get an Authorization Code. A malicious attacker can only intercept the Authorization Code and swap it for a token if the Code Verifier is not present.

Use Cases

Apps that must serve unknown public consumers that may pose extra security risks that the Auth Code Flow does not handle.

Conclusion

As you might have imagined, the OAuth flows should be chosen carefully in order to better your use case and address specific challenges. For instance, you may have a single application that requires access tokens for many asset servers. Several calls to/approve will be required.

OAuth Flows are a method of receiving Access Tokens, and the appropriate flow for your use case is decided by the type of app. Other considerations to consider are the level of confidence in the application and the intended user experience.

Today, making the wrong decision might have serious security and consistency ramifications.