Skip to main content

Hybrid Flow

This article explains what the OIDC Hybrid Flow (Grant Type) is and how it works.

What Hybrid Flow Is

The OpenID Connect Hybrid flow combines the capabilities of the implicit flow and the authorization code grant flow. This flow allows the client to receive both an ID token and an authorization code as the result of a request to the /authorize endpoint, but, the client can use the code exchange to obtain access and refresh tokens via a request to the /token endpoint.

Hybrid flow can be used by the clients that are able to securely store their client secrets. It gives the clients the possibility to have access to an ID token as soon as possible and, at the same time, to securely retrieve access and refresh tokens. You can use the hybrid flow if the client needs to perform some additional processing before requesting tokens and providing the authorization code in the request.

How Hybrid Flow Works

Hybrid_Flow.svg

  1. A user tries to access the application (the client).

  2. The client redirects the user to the authorize endpoint.

    Note

    The client must inform SecureAuth of its desired grant type by using the response_type parameter. For the hybrid grant flow, the response_type can have the following values:

    • code id_token - a successful response contains both an authorization code and an ID token.

    • code token - a successful response contains an authorization code, an access token and an access token type.

    • code id_token token - a successful response contains an authorization code, an ID token, an access token, and an access token type.

    To learn more about multiple-valued response type combinations, see the OAuth 2.0 Multiple Response Type Encoding Practices specification.

  3. SecureAuth authenticates the user and displays a consent screen if there is an authorization scope to be granted.

    Note

    Note

    Cloudentity does not display the consent screen when there is no authorization scope to be granted.

  4. The user gives their consent.

  5. SecureAuth issues an authorization code and one or more additional parameters depending on the value for the response_type parameter provided in the second step.

    Note

    After SecureAuth generates the authorization code, it is redirected to the redirection endpoint configured for the registered client. The client must have at least one registered redirection URI. If there are multiple registered redirection URIs, the request to the authorize endpoint must always include the redirect_uri parameter. If there is only one registered redirection URI for the client, it does not have to include the redirect_uri parameter in the request to the authorize endpoint.

  6. The client performs a request to the token endpoint using authorization code provided in the previous step.

    Read More

    To learn more about token endpoint authentication methods, see the client authentication documentation.

  7. SecureAuth validates the request.

  8. SecureAuth returns the token.

  9. The client requests protected resources from the resource server and submits the token it received in the previous step.

  10. The resource server validates the token and responds the requested resources.

In this section: