Policies

Policies define how client and resource server are communicating.

Implicit flow

If the client cannot securely store its client secret and refresh token (see type "public" in the chapter "Client"), the access tokens and ID tokens are issued directly by the authorization endpoint when the client ID is presented (see the OAuth 2.0 Authorization Framework, chapter "Implicit Grant")..

Client credential flow

A client can request an access token using only its client credentials. The credentials should only be used when there is a high degree of trust between the resource owner and the client (e.g., the client is part of the device operating system or a highly privileged application), and when other authorization grant types are not available (such as an authorization code), see the OAuth 2.0 Authorization Framework, chapter Client Credentials Grant.

Authorization code flow

An authorization code must be requested from the authorization server using the client ID and client secret. The client then exchanges the acquired authorization code for access and refresh tokens from the token endpoint, see the OAuth 2.0 Authorization Framework, chapter Authorization Code Grant.

Refresh token request

Refresh tokens are issued to the client by the authorization server and are used to obtain a new access token when the current access token becomes invalid or expires, or to obtain additional access tokens with identical or narrower scope (access tokens may have a shorter lifetime and fewer permissions than authorized by the resource owner), see the OAuth 2.0 Authorization Framework, chapter Refresh Token. The policy defines if user consent is required to issue a refresh token.

Force re-authentication

For sensitive scopes, the client may have to let the user explicitly re-authenticate at the resource provider. The policy defines if re-authentication is required for a client.