Overview of OIDC authentication

This topic provides and overview of the authorization flows that are supported by OpenID Connect.

CyberArk Identity performs an authentication to log in to the end-user or to determine if the user is already logged in. The authentication result is then securely returned to the client so that the client can rely on it. For this reason, the client is also called a relying party. The authentication result is returned in an ID token.

The relying party (RP) can obtain the ID token and access token using authorization flows. The authorization flow depends on the type of RP. OpenID Connect supports the following authorization flows:

  • Integrate the authorization code flow: Use the authorization (auth) code flow for applications that can maintain the secrecy of a client secret (for example, server-side Javascript). In this flow, the OpenID Provider (OP) issues a temporary authorization code through redirection, which is not exposed to the user once the user is authenticated. The client (the application) sends this authorization code to a token endpoint on the OP. The OP, in turn, returns the final ID and access tokens to the client (again through a back channel). Note that the application's client secret is also sent to help ensure that only authorized client applications can request an access token.

  • Integrate the authorization code flow with PKCE is a variant of the authorization code flow where, instead of a client secret, a code challenge and code verifier are used. The PKCE flow is recommended for public clients such as SPAs and mobile applications, because client secrets need not be maintained.

  • Integrate the implicit flow: Use the implicit flow for applications that cannot maintain the secrecy of a client secret (for example, browser-based applications). The application obtains an access token directly in an authorization request (via a redirect), over a secure communication channel, with no intermediate authorization code requested or returned.

  • Integrate a hybrid flow: Use a combination of the previous two authorization flows for applications that can maintain the secrecy of a client secret but don't require the use of a client ID/secret.

The flow used is determined by the response_type value contained in the authorization request. The following response_type values select the flows:

"response_type" value



Authorization code flow


Implicit flow

id_token token

Implicit flow

code token

Hybrid flow

code token id_token

Hybrid flow

code id_token

Hybrid flow