response types and flows

What’s a Response Type?

When working with OIDC, you’ll hear talk of various “flows”. These flows are used to describe different common authentication and authorization scenarios.

Considerations include:

• the type of application (like web-based or native mobile app),
• how you want to validate tokens (in the app or in the backend),
• and how you want to access additional identity information (make another API call or have it encoded right into a token).

There are three primary flows:

1. Authorization Code,
2. Implicit,
3. and Hybrid.

These flows are controlled by the response_type query parameter in the /auth request. When thinking of which flow to use, consider front-channel vs. back-channel requirements.

Front-channel refers to a user-agent (such as a SPA or mobile app) interacting directly with the OpenID provider (OP). The implicit flow is a good choice when front-channel communication is required.

Back-channel refers to a middle-tier client (such as Spring Boot or Express) interacting with the OP. The authorization code flow is a good choice when back-channel communication is required.

A little word about the flows

Authorization Code flow uses response_type=code.
After successful authentication, the response will contain a code value. This code can later be exchanged for an access_token and an id_token (Hang in for now, we’ll talk about tokens in more depth later on.) This flow is useful where you have “middleware” as part of the architecture. The middleware has a client id and client secret, which is required to exchange the code for tokens by hitting the /token endpoint. These tokens can then be returned to the end-user application, such as a browser, without the browser ever having to know the client secret. This flow allows for long-lived sessions through the use of refresh tokens. The only purpose of refresh tokens is to obtain new access tokens to extend a user session.

Implicit flow uses response_type=id_token token or response_type=id_token.
After successful authentication, the response will contain an id_token and an access_token in the first case or just an id_token in the second case. This flow is useful when you have an app speaking directly to a backend to obtain tokens with no middleware. It does not support long-lived sessions.

Hybrid flow combines the above two in different combinations – whatever make sense for the use case. An example would be response_type=code id_token. This approach enables a scenario whereby you can have a long lived session in an app and get tokens back immediately from the /authorization endpoint.