OAuth 2.0 is an open-standard framework and specification for authorizing client applications to access online resources. Authorization works by requiring a client to obtain an access token from a server that in turn grants the client access to specific protected resources. The client then sends the access token to the resource whenever it invokes the resource's endpoints.
CyberArk Identity supports OAuth 2.0, allowing custom CyberArk Identity client applications access to online resources needed by those applications.
You can configure a CyberArk Identity tenant and client applications to handle different flows whereby different requirements and API calls are in place to obtain the access token
- Setup the OAuth2 client custom application and select the appropriate auth method.
Client Credentials Flow: In this flow, the client application provides a client ID and client secret to obtain an access token from a tenant. For more information see the: Client Credentials Flow RFC.
Resource Owner Flow: in this flow, the client application provides its own user interface in which the user enters their credentials and grants access to resources. This information is then sent to the CyberArk Identity server which returns an access token to the client. Since this flow does not involve redirection to a CyberArk Identity popup to obtain authorization, it should only be used in highly privileged client applications such as native applications running on an OS. For more information see the Resource Owner Flow RFC.
Note: The below flows work similarly in OAuth 2.0 as in the OpenID Connect protocol. As OIDC is an identity layer on top of OAuth, the only difference is in OIDC, we get an ID token, whereas, in OAuth, we get only an access token.
Authorization (Auth) Code Flow: in this flow, the client redirects the user to a CyberArk Identity popup where the user enters their credentials and grants access. The OAuth server then returns an authorization code to the client. The client then sends a request to the OAuth server to obtain a bearer authorization token and includes the authorization code in this request. The OAuth server then returns the authorization and refresh token to the client for use in accessing subsequent endpoints. For more information see the Authorization Code Flow RFC
Authorization Flow with PKCE is a variant of authorization code flow where instead of client secret, code challenge and code verifier are used. The PKCE flow is recommended for public clients such as SPAs and mobile applications, as client secrets need not be maintained.
You can obtain information about token signing using the following endpoints:
/oauth2/<servicename>/keys: provides information on the public elements of the key in use for token signing.
/oauth2/getmeta?<servicename>provides information on the service itself and the RFC endpoint URIs it supports.
Updated about 2 months ago