Grant types or flow types are a way to specify how a client wants to interact with IdentityServer. It's an approach that allows clients to obtain token(s) from the OP through endpoints. The whole life cycle of any Authentication & Authorization request is bound by one of the flows. The OpenID Connect (OIDC) and OAuth2 specs define the following types:

• Authorization code
• Implicit
• Resource owner password credentials
• Client credentials
• Refresh tokens
• Hybrid
• Device flow
• Extension grants

The main purpose of introducing multiple flow/grant types is to authenticate & authorize access to protected resources in various ways with different security credentials due to the variation of HTTP services based application architectures.

Grant types and flow types are essentially the same. The former is OAuth2 and the latter is OIDC derived. Flow can replace grant in the rest of this page.

There are three typical grant types currently used by CRMLS: implicit, resource owner password credentials, and client credetials. Basically, client applications that deal with end users would use implicit (recommended) or resource owner password credentials grant types while machine to machine applications would use the client credentials type. CRMLS can work with client application developers to configure the proper grant type that is allowed that best fits their use case(s).

The discovery document (disco doc) lists CRMLS OP grant types among other things (e.g., the issuer name, key material, supported scopes etc.).

Here is a portion of the json from the CRMLS OP discovery document that is relevant to grant/flow types.

{
  "authorization_endpoint": "https://soc.crmls.org/connect/authorize",
  "token_endpoint": "https://soc.crmls.org/connect/token",
  "grant_types_supported": [
    "authorization_code",
    "client_credentials",
    "refresh_token",
    "implicit",
    "password",
    "urn:ietf:params:oauth:grant-type:device_code"
  ],
  "response_types_supported": [
    "code",
    "token",
    "id_token",
    "id_token token",
    "code id_token",
    "code token",
    "code id_token token"
  ],
}

All Authorization/Authentication requests within all flow types are received by either one or both of the two endpoints - authorization_endpoint & token_endpoint.

authorization_endpoint - Used to request: (typically through a web browser or web view)

• identity token, access token, or both tokens (implicit flow & hybrid flow).
• authorization codes (authorization code flow and hybrid flow).

token_endpoint - Used to programmatically request or refresh tokens (authorization code flow, hybrid flow, resource owner password credentials flow, client credentials flow or custom grant types).

• All requests to the token endpoint must be authenticated - either pass client id and secret via Basic Authentication or add client_id and client_secret fields to the POST body.
• OIDC authentication is associated with authenticating an end user's identity, in OAuth2 all flows require authentication but not in the context of an end user's identity (e.g., client credential flow is not meant to have an end user).

Further descriptions of CRMLS OP's typical flows are given below.

Client Credentials

This flow type is purely OAuth2 where OIDC plays no part because there is no end user identity involved (i.e., id_token can not be obtained). This means this flow is meant for machine-to-machine applications where the system authenticates and authorizes the app rather than a user. In addition, because the client does not require user approval a refresh token is not required since a new token can be obtained at any time.

Access token, the only token type within this flow, is returned from the token endpoint.

The diagram below depicts a typical interaction between the client, server, and resource (e.g. ODataApi).

Resource Owner Password

This flow is another purely OAuth2 flow where no end user identity is involved (i.e., id_token not obtained). Although the user provides user credentials, the client uses them to aquire an access token from the OP. This grant/flow type carries a higher risk than other grant types because it maintains the password anti-pattern OAuth2 protocol seeks to avoid.

Should only be used when there is a high degree of trust between the resource owner and the client, and when alternative flows (like Authorization Code Flow) are not available/viable. The OP and client SHOULD minimize use of this grant type and utilize other grant/flow types whenever possible.

Implicit

The implicit flow requests tokens without explicit client authentication, instead using the redirect URI (which is registered within the OP's configuration for the client) to verify the client's identity. Because of this, refresh tokens are not allowed, nor is this flow suitable for long lived access tokens. From the client application's point of view, this is the simplest to implement, as there is only one round trip to the OP.

This flow obtains all tokens from the authorization endpoint.

Response Type

The respose_type is a parameter that is set at the client side and passed to the OP during token requests. This parameter coincides with the grant type that was configured for the client within the system and what response types are enabled by the system. The disco doc also lists CRMLS OP response types.

A client can be configured to use more than a single grant type (e.g. Hybrid for user centric operations and client credentials or authorization code for server to server communication). The flow type given to a client dictates the response type it can set.

CRMLS recommended response_type setting for implicit flow:

// This is the typical setting for reponse_type at the client.
response_type: "id_token token"

As stated before: CRMLS will work with the client to register the proper grant/flow type(s) for the RP based on it's use case(s).

References/Sources

• OpenID Connect Flows, by Scott Brady
• Flow Types and Origin, by Jawad Al Shaikh