The OAuth 2.0 Authorization Framework supports several different flows (or grants). are ways of retrieving an . Deciding which one is suited for your use case depends mostly on your application type, but other parameters weigh in as well, like the level of trust for the client, or the experience you want your users to have.

​
OAuth 2.0 terminology

  • : Entity that can grant access to a protected resource. Typically, this is the end-user.
  • Client: Application requesting access to a protected resource on behalf of the Resource Owner.
  • : Server hosting the protected resources. This is the API you want to access.
  • : Server that authenticates the Resource Owner and issues Access Tokens after getting proper authorization. In this case, Auth0.
  • User Agent: Agent used by the Resource Owner to interact with the Client (for example, a browser or a native application).

​
Is the Client the Resource Owner?

The first decision point is about whether the party that requires access to resources is a machine. In the case of machine-to-machine authorization, the Client is also the Resource Owner, so no end-user authorization is needed. An example is a cron job that uses an API to import information to a database. In this example, the cron job is the Client and the Resource Owner since it holds the and and uses them to get an Access Token from the Authorization Server. If this case matches your needs, then to learn how this flow works and how to implement it, see Client Credentials Flow.

​
Is the Client a web app executing on the server?

If the Client is a regular web app executing on a server, then the Authorization Code Flow is the flow you should use. Using this the Client can retrieve an Access Token and, optionally, a . It’s considered the safest choice since the Access Token is passed directly to the web server hosting the Client, without going through the user’s web browser and risking exposure. If this case matches your needs, then to learn how this flow works and how to implement it, see Authorization Code Flow.

​
Is the Client absolutely trusted with user credentials?

This decision point may result in the Resource Owner Password Credentials Grant. In this flow, the end-user is asked to fill in credentials (identifier/password), typically using an interactive form. This information is sent to the backend and from there to Auth0. It is therefore imperative that the Client is absolutely trusted with this information. This grant should only be used when redirect-based flows (like the Authorization Code Flow) are not possible. If this is your case, then to learn about how this flow works and how to implement it, see Resource Owner Password Flow.

​
Is the Client a Single-Page App?

If the Client is a Single-Page App (SPA), an application running in a browser using a scripting language like JavaScript, there are two grant options: the Authorization Code Flow with Proof Key for Code Exchange (PKCE) and the Implicit Flow with Form Post. For most cases, we recommend using the Authorization Code Flow with PKCE because the Access Token is not exposed on the client side, and this flow can return Refresh Tokens. To learn more about how this flow works and how to implement it, see Authorization Code Flow with Proof Key for Code Exchange (PKCE). The Auth0 Single-Page App SDK provides high-level API for implementing Authorization Code Flow with PKCE in SPAs. If your SPA doesn’t need an Access Token, you can use the Implicit Flow with Form Post. To learn more about how this flow works and how to implement it, see Implicit Flow with Form Post.

​
Is the Client a Native/Mobile App?

If the Application is a native app, then use the Authorization Code Flow with Proof Key for Code Exchange (PKCE). To learn more about how this flow works and how to implement it, see Authorization Code Flow with Proof Key for Code Exchange (PKCE).

​
I have an application that needs to talk to different resource servers

If a single application needs access tokens for different resource servers, then multiple calls to /authorize (that is, multiple executions of the same or different ) needs to be performed. Each authorization will use a different value for audience, which will result in a different access token at the end of the flow. For more information, see the OAuth 2.0: Audience Information Specification.

​
Can I try the endpoints before I implement my application?

Sure! You can use our Authentication API Debugger Extension. You can find detailed instructions per /grant endpoint at our Authentication API Reference.
  • For the Authorize endpoint, go to Authorize Application and read the “Test this endpoint” paragraph for the grant you want to test.
  • For the , go to Get Token and read the “Test this endpoint” section for the grant you want to test.

​
Does the Client Application need to challenge users for authentication without browser interaction?

Client-Initiated Backchannel Authentication is currently in Early Access. To enable CIBA, contact your Technical Account Manager.
Client-Initiated Backchannel Authentication (CIBA) is an Foundation standard for implementing an alternative authentication flow to OpenID Connect. CIBA differs from the standard OpenID Connect flow in that:
  • The client application initiates the authentication process on behalf of the end user.
  • There’s no need for a browser for user interaction.
  • There’s direct communication between the client application and the OpenID Provider.
CIBA is useful when the user can’t trust the client application, the client application doesn’t have a browser, or the user is not in front of the application that requires authentication. Here are some examples of where CIBA flows can be used:
  • User check-in at a retail sales terminal: For click-collect scenarios, a user can authenticate at a public kiosk and confirm their presence.
  • Authenticating in a call center or at a clerk’s desk: A call center agent can initiate an authentication flow to authenticate a caller, typically using a custom mobile app on a smartphone.
  • Authenticating on a device with no input: For example, a smart speaker (or another connected device) can use a backend service to contact the user for authentication, typically using a custom mobile app on a smartphone.
CIBA defines two devices:
  • Consumption device: The device that helps the user consume a service.
  • Authentication device: The device on which the user will authenticate and grant consent.
To learn more, read Client-Initiated Backchannel Authentication Flow.