ACP hybrid flow

This article explains what the hybrid grant flow type is and how it works.

Hybrid flow in a nutshell

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.

Flow diagram

[mermaid-begin]
sequenceDiagram participant User participant Client application participant ACP tenant participant API activate User User->>Client application: Access activate Client application Client application->>ACP tenant: Request authorization activate ACP tenant deactivate Client application ACP tenant->>User:Display consent User->>ACP tenant: Authenticate and give consent deactivate User ACP tenant->>Client application: Issue authorization code and one or more parameters activate Client application Client application->>ACP tenant: Request token ACP tenant->>ACP tenant: Verify the authorization code ACP tenant->>Client application: Return token deactivate ACP tenant Client application->>API: Call API with token activate API API->>Client application: Return data deactivate API deactivate Client application

Hybrid flow in depth

  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 ACP 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. ACP authenticates the user and displays a consent screen if there is an authorization scope to be granted.

    Note

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

  4. The user gives their consent.

  5. ACP 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 ACP 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. ACP validates the request.

  8. ACP 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.