Which OAuth Flow Should I Use?
On this page
OAuth flows were first introduced in 2012. Since then, best practices have changed and some older flows are no longer recommended for security reasons. This article provides a brief summary of up to date flows that you should follow, so that your solutions align with current best practices. Luckily, there is a short answer.
The Short Answer
When in doubt and if possible, choose the Code Flow for your application. Curity provides many code examples and guides on how to run the code flow for different technologies.
Making a Decision
The default option for applications should be the code flow with PKCE. There are situations, however, where other flows are more applicable. The following decision tree guides you to the right solution.
To be able to make the right choice, it is necessary to understand some characteristics about the application and the use case. The remaining article goes through each question and provides the rational for each choice so that you can make an informed decision.
Are Users Involved?
OAuth 2.0 contains two main categories of authorization flows:
- User-centric flows - where the authorization server should authenticate a user.
- Machine-to-machine flows - where the client acts without user interaction.
If users are involved, the flow must facilitate user authentication via a user interface. Once authentication completes, access tokens that clients receive should contain the user identity and other user attributes as claims. When the client sends API requests, all APIs that receive the access token then receive a verifiable user identity.
For cases where the client only operates in a machine-to-machine scenario, the client can communicate directly with the authorization server. To get an initial token that represents the client and not a user, use the Client Credentials Flow.
Client Credentials Flow
Use the client credentials flow to get an access token in machine-to-machine scenarios.
Can Users Authenticate on the Same Device?
When the authorization server authenticates users, it needs to select the appropriate user interface to interact with the users. There are two approaches to trigger user interactions:
- Same-device authentication: redirect approach on same device.
- Cross-device authentication: decoupled approach for different devices.
Same-device Authentication
Users can authenticate on the same device via a redirect approach, if they can interact with the client and if the device they use is capable of opening a browser for authentication. In this case, the Code Flow is a strong candidate for the client to get access tokens.
Authorization Code Flow
Consider the OAuth 2.0 code flow to authenticate users in same-device scenarios.
Cross-device Authentication
Users may not be able to authenticate on the same device that they use to interact with the client. For example, devices like TVs, IoT devices, or remote consoles may not be able to open a browser or have input constraints.
If the user can interact with the client, and if the client can communicate a code and link (or QR code) to the user for authentication on a different device, then consider the Device Flow for the decoupled approach.
What if the User is Remote?
In some use cases you may need to request users to authenticate remotely. For example, a helpdesk might require this type of flow. In this case, someone else runs the client and the client cannot communicate the authentication information directly to the user. If the client cannot communicate the authentication information to the user, then choose the Client-Initiated Backchannel Authentication (CIBA) Flow. To use the CIBA flow the user must have enrolled at the authorization server out of band, and the client needs to collect a user identifier so that the authorization server can trigger authentication of the correct user.
Decoupled Authentication
Use the device flow for cross-device authentication and the CIBA flow for remote authentication.
Is the User Running a Browser-Based Application?
Browser-based applications imply certain risks that we outline in detail in Token Handler Pattern for SPAs. Essentially, access tokens in the browser (even in memory) are problematic. The best way to handle OAuth for browser-based apps is to utilize cookies via the Token Handler.
What About First-Party OAuth Implementations?
OAuth, while designed for third-party scenarios, is incredibly useful in same-party scenarios as well, that is for first-party apps. In this scenario, the client, the authorization server, and APIs are from the same party. The authorization server fully trusts the client because it is developed and maintained by the same party.
The paradigm change opens up for new possibilities and improving user experience for OAuth integrations. You may want to take a look at OAuth 2.0 for First-Party Applications. At Curity we provide the Hypermedia Authentication API (HAAPI) with related SDKs for that purpose.
Summary
For many cases, the OAuth 2.0 Code Flow with PKCE is the right choice for OAuth clients, but other flows exist for good reasons. This guide outlined some questions and arguments for choosing the right OAuth flow.
Judith Kahrer
Product Marketing Engineer at Curity
Join our Newsletter
Get the latest on identity management, API Security and authentication straight to your inbox.
Start Free Trial
Try the Curity Identity Server for Free. Get up and running in 10 minutes.
Start Free Trial
