Skip to main content
Version: 8.2411.x.x RR

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.

JWT bearer token request​

To use a Bearer JWT as an authorization grant, the client uses an access token request as defined in Section 4 of the OAuth Assertion Framework with specific parameter values and encodings, see at Using JWTs as Authorization Grants.

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.