Category: OAuth & OIDC

Hybrid Flow

Also known as: OIDC Hybrid Flow

Simply put

Hybrid Flow is an OpenID Connect sign-in method that blends features of two other flows so an application can receive some information immediately from the login server while still securely retrieving the rest through a follow-up exchange. In practice, this lets an app get an initial token right away and then obtain additional tokens in a more protected way.

Formal definition

Hybrid Flow is an OpenID Connect Core 1.0 authentication flow, built on OAuth 2.0, in which the Authorization Endpoint returns an Authorization Code together with one or more tokens (for example an ID Token and/or Access Token, depending on the requested response_type such as code id_token, code token, or code id_token token). It combines characteristics of the Authorization Code Flow and the (now discouraged) Implicit Flow: the client may receive an ID Token directly from the Authorization Endpoint for immediate use, while the returned Authorization Code is subsequently redeemed at the Token Endpoint for tokens (which, depending on configuration, may include Access Tokens and Refresh Tokens). Because OIDC layers authentication on top of OAuth 2.0's delegated authorization, the ID Token conveys the authentication result while any Access Token governs authorization to resources. Note that any tokens delivered via the Authorization Endpoint are exposed in front-channel responses and must be validated per OIDC Core; exact token types and security properties vary by response_type, profile, and vendor deployment.

Why it matters

Hybrid Flow addresses a specific architectural need: some applications require an authentication result immediately at the point of redirect while still needing to obtain longer-lived or more sensitive tokens through a back-channel exchange. By returning an ID Token directly from the Authorization Endpoint, a client can begin establishing a user session or rendering personalized content without waiting for a separate Token Endpoint round trip, while the accompanying Authorization Code preserves a more protected path for retrieving Access Tokens and, depending on configuration, Refresh Tokens.

The trade-off is that any token delivered through the Authorization Endpoint travels in a front-channel response, meaning it is exposed to the browser and potentially to intermediaries such as the user agent, browser history, or referrer headers. This is the same exposure characteristic that led the Implicit Flow to fall out of favor, and it is why tokens returned via the front channel must be validated according to OIDC Core rather than trusted implicitly. Teams adopting Hybrid Flow should weigh whether the immediate availability of an ID Token justifies the additional handling and validation burden, since the security properties vary by the requested response_type, the applicable profile, and the specific vendor deployment.

Because OpenID Connect layers authentication on top of OAuth 2.0's delegated authorization framework, Hybrid Flow keeps these concerns distinct: the ID Token conveys the authentication result, while any Access Token governs authorization to resources. Confusing the two, for example, treating an Access Token as proof of who the user is, remains a recurring source of implementation error, and Hybrid Flow's simultaneous delivery of multiple token types makes disciplined validation of each token especially important.

Who it's relevant to

IAM Engineers and Application Developers

Engineers integrating OpenID Connect sign-in need to understand when Hybrid Flow's immediate ID Token delivery is worth the added front-channel exposure, and how to correctly redeem the Authorization Code at the Token Endpoint for Access and Refresh Tokens. They are responsible for validating every token per OIDC Core and for choosing an appropriate response_type for their use case.

Security Architects

Architects evaluating authentication flows must weigh Hybrid Flow against the Authorization Code Flow, recognizing that tokens returned from the Authorization Endpoint travel in the front channel and carry the same class of exposure that led the Implicit Flow to be discouraged. They set guidance on which flows and profiles are permitted in their environment.

Compliance and Audit Teams

Reviewers assessing how applications authenticate users benefit from understanding that Hybrid Flow delivers an ID Token conveying the authentication result separately from any Access Token governing authorization. This distinction matters when verifying that authentication and authorization are handled correctly and that front-channel tokens are validated as required.

Inside Hybrid Flow

OpenID Connect authorization response

Hybrid Flow is an OpenID Connect authentication flow (defined in OIDC Core) in which multiple artifacts are returned directly from the authorization endpoint rather than exclusively from the token endpoint. It combines characteristics of the authorization code flow and the implicit flow.

response_type combinations

The flow is triggered by combined response_type values, typically 'code id_token', 'code token', or 'code id_token token'. The presence of 'code' alongside 'id_token' and/or 'token' is what makes the flow hybrid, since some artifacts arrive at the front channel and the code is later exchanged at the token endpoint.

Authorization code

A short-lived code returned from the authorization endpoint that the client subsequently exchanges at the token endpoint, typically over a back-channel request, for tokens. This exchange step supports delegated authorization consistent with the underlying OAuth 2.0 framework.

ID token

A signed JWT conveying authentication claims about the end user. In Hybrid Flow an ID token may be returned directly from the authorization endpoint (front channel), where it can be used to validate the response before completing the code exchange. Being signed provides integrity and authenticity but does not by itself imply the token is encrypted.

Access token

When 'token' is included in the response_type, an access token may be returned from the authorization endpoint. Access tokens are used for delegated authorization to resources and are distinct in purpose from the ID token, which carries authentication information.

Front-channel and back-channel delivery

Hybrid Flow splits artifact delivery: certain tokens or the code arrive via the front channel (browser redirect/URI fragment), while the token exchange for the code typically occurs via the back channel. This split is a defining structural characteristic and has security implications depending on which artifacts are exposed in the front channel.

Common questions

Answers to the questions practitioners most commonly ask about Hybrid Flow.

Is the Hybrid Flow just another name for the Authorization Code Flow with an extra step?

No. The Hybrid Flow is a distinct OpenID Connect (OIDC Core) flow selected by using a response_type that combines code with token and/or id_token (for example code id_token). Unlike the Authorization Code Flow, where the client receives only an authorization code from the authorization endpoint and exchanges it at the token endpoint, the Hybrid Flow returns some tokens directly from the authorization endpoint alongside the code. This changes where and when tokens are delivered, so it is a different flow rather than the Authorization Code Flow with an added step.

Does receiving an ID token directly from the authorization endpoint mean the Hybrid Flow authenticates the user twice?

No. Returning an id_token from the authorization endpoint does not imply a second authentication event. It reflects that OIDC (an authentication layer built on OAuth 2.0) can deliver the id_token as a front-channel result while still allowing the client to obtain further tokens via the back-channel code exchange. The user is authenticated once at the authorization server; the flow determines how the resulting tokens are distributed, not how many times the principal is authenticated. Note that tokens delivered via the front channel typically require careful validation, as described below.

What validation should a client perform on tokens returned directly from the authorization endpoint in the Hybrid Flow?

Because some tokens arrive via the front channel, clients should validate them rather than trust them implicitly. This typically includes verifying the id_token signature against the authorization server's published keys, checking issuer, audience, and expiry claims, and validating the nonce to bind the token to the request. Depending on the response_type, OIDC Core also defines detached-signature-style parameters such as c_hash and at_hash that allow a client to verify that the code and any front-channel access token correspond to the returned id_token. Exact required checks depend on the response_type and deployment profile.

When would an implementation choose the Hybrid Flow over the Authorization Code Flow?

In most deployments, the Authorization Code Flow (frequently with PKCE) is the recommended default. The Hybrid Flow is typically considered when an application benefits from obtaining an id_token immediately from the authorization endpoint, for example to establish a session or make early authorization or routing decisions in the client, while still retrieving other tokens through the back-channel code exchange. The suitability depends on the client type and security requirements; front-channel token exposure is a factor to weigh against any latency or UX benefit.

How does response_mode interact with the Hybrid Flow?

Because the Hybrid Flow can return tokens from the authorization endpoint, the response_mode governs how those parameters are delivered back to the client. Returning tokens in a URL query string is generally discouraged for token-bearing responses; fragment or form_post response modes are commonly used instead to reduce exposure of tokens in URLs, logs, or referrer headers. The available response_mode options and their behavior depend on the authorization server and the specific OIDC profile in use.

What are the security considerations for handling front-channel tokens in the Hybrid Flow?

Front-channel delivery means tokens or their identifiers can pass through the user agent, so implementations should minimize exposure. Considerations typically include using nonce to prevent replay, validating c_hash and at_hash where applicable to detect substitution of the code or access token, avoiding placement of tokens in query strings, and protecting against leakage via browser history, logs, or referrer headers. Whether an access token is returned via the front channel at all depends on the chosen response_type, and clients should limit front-channel token issuance to what the application actually requires.

Common misconceptions

Hybrid Flow is just OAuth 2.0 returning tokens in a different way.

Hybrid Flow is an OpenID Connect flow (OIDC Core) that adds an authentication layer on top of the OAuth 2.0 authorization framework. It returns ID tokens conveying authentication claims, which OAuth 2.0 alone does not define. Treating it as pure OAuth 2.0 conflates delegated authorization with user authentication.

Because an ID token returned in Hybrid Flow is signed, its contents are protected from disclosure.

Signing provides integrity and authenticity, not confidentiality. A signed JWT is not encrypted unless additional encryption (for example JWE) is applied. Artifacts returned via the front channel can be exposed in the browser, so signing alone does not conceal their contents.

Hybrid Flow is always the most secure or most appropriate choice because it returns more artifacts.

Returning tokens through the front channel increases exposure surface, and suitability depends on the deployment context, client type, and standard profile. In many modern deployments the authorization code flow with PKCE is preferred; Hybrid Flow is not universally superior and should be selected based on specific requirements.

Best practices

Validate the ID token returned from the authorization endpoint, including its signature and claims, before relying on it or completing the authorization code exchange.

Select response_type combinations deliberately ('code id_token', 'code token', or 'code id_token token') and expose only the artifacts you actually need in the front channel to limit exposure.

Perform the authorization code exchange over the back channel at the token endpoint, and treat any access token exposed in the front channel as higher risk depending on your configuration.

Apply encryption (for example JWE) in addition to signing when confidentiality of token contents is required, rather than assuming a signed JWT is protected from disclosure.

Keep authentication concerns (ID token, user identity claims) distinct from authorization concerns (access token, resource access) when handling the returned artifacts.

Evaluate whether Hybrid Flow is warranted for your client type and profile, and consider the authorization code flow with PKCE where front-channel token exposure is not needed.