How To: OAuth 2.0 / OpenID Connect Flows: Overview

Version Affected: All 

 

Overview

The SecureAuth Identity Provider (IdP) supports several OAuth 2.0 / OpenID Connect (OIDC) flows (also called grant types) for obtaining a token. Each flow suits a different kind of application, and some flows carry more security risk than others. This article explains what each flow is, the communication pattern between the browser, the application, and the IdP, and when you should (or should not) use it.

For the exact steps to make a test call for each flow, see How To: Test OAuth / OpenID Connect Flows.

In this article

• Client Credentials flow
• Implicit flow
• Hybrid flow
• Authorization Code flow
• Resource Owner Password flow

Client Credentials flow

The application authenticates directly to the IdP using the client_id and client_secret, with no browser and no end user involved.
 

Use this when: a server-side application or service needs a token for its own machine-to-machine calls, with no end user involved (for example, a nightly batch job calling an API).

Should you use it? Yes, for machine-to-machine use cases — this is the flow OAuth 2.0 recommends for that scenario. Only use it from a trusted backend that can keep client_secret confidential; never use it in a browser, mobile app, or any client the end user has access to, since the secret would be exposed.

Implicit flow

The browser gets a token directly from the authorization endpoint in a redirect, without the application's backend ever calling the token endpoint.
 

Use this when: historically, a browser-only application (no backend server) needed a token without a server-side component to call the token endpoint.

Should you use it? No — this flow is no longer recommended. Current OAuth 2.0 security guidance advises against the Implicit flow because it returns the token directly in the browser's URL, where it can be exposed through browser history, referrer headers, or logs. Use the Authorization Code flow with Proof Key for Code (PKCE) instead, which is now the recommended approach for browser-based and mobile applications. Implicit is documented here for legacy applications that still use it.

Hybrid flow

The browser gets an authorization code together with a token (or tokens) in the same redirect from the authorization endpoint. The application can use the token(s) immediately, and can also exchange the code at the token endpoint afterward.
 

Use this when: an application needs an ID token immediately in the browser (for example, to sign the user in right away) while also collecting a code it can redeem server-side for additional, longer-lived tokens.

Should you use it? It has a legitimate niche, but it is more complex than it needs to be for most applications. For most new applications, prefer the Authorization Code flow with PKCE: it achieves the same outcome (an immediate sign-in plus tokens the backend can use) without exposing any token in the browser URL, which Hybrid still does for the token(s) returned in step 2.

Authorization Code flow

The browser gets a short-lived authorization code from the authorization endpoint. The application's backend then exchanges that code for tokens directly with the token endpoint — tokens are never exposed in the browser.
 

Use this when: this is the general-purpose flow for most applications — web applications with a backend, and (with the PKCE extension) single-page applications and mobile apps too.

Should you use it? Yes — this is the recommended flow for most applications. Tokens are only ever exchanged directly between the application's backend and the IdP's token endpoint, never passed through the browser. For applications that cannot keep a client_secret confidential (single-page apps, mobile apps), add the PKCE extension to this flow rather than falling back to Implicit.

Resource Owner Password flow

The application collects the end user's username and password directly and sends them to the IdP's token endpoint in exchange for a token. Also known as the Password grant.
 

Use this when: historically, this was used by highly trusted first-party applications (built by the same organization that runs the IdP) that needed to accept a username and password directly, without a browser redirect.

Should you use it? No, avoid it for new applications. The application handles the user's raw password directly, which trains users to enter credentials into third-party applications and removes the IdP's ability to enforce multi-factor authentication or other login-time policies. Use the Authorization Code flow instead, even for first-party applications.

 

SecureAuth Knowledge Base Articles provide information based on specific use cases and may not apply to all appliances or configurations. Be advised that these instructions could cause harm to the environment if not followed correctly or if they do not apply to the current use case.

Customers are responsible for their own due diligence prior to utilizing this information and agree that SecureAuth is not liable for any issues caused by misconfiguration directly or indirectly related to SecureAuth products.