CyberArk Identity supports OpenID Connect (OIDC), one of the popular authentication protocols, and can be leveraged for federated SSO.
This document provides an overview of OIDC, application config on the CyberArk Identity Admin portal, and user authentication to custom applications using CyberArk Identity's OIDC protocol.
OpenID Connect is a simple identity layer on top of the OAuth 2.0 protocol. It enables Clients to verify the identity of the End-User based on the authentication performed by an Authorization Server, as well as to obtain basic profile information about the End-User in an interoperable and REST-like manner.
An application that accesses protected resources on behalf of users must be able to verify that users are who they claim to be. One way to enable an application to verify users is by creating a database of usernames and passwords, but using a database is unsatisfactory. It is time-consuming, requires your users to register and remember the usernames and passwords, and needs your client application and server to access them.
It also becomes challenging to maintain the user's access to multiple applications, as the user has to keep a set of credentials for each application.
A better solution is to leverage an existing, trustworthy identity provider (IDP) that can authenticate large volumes of users with which your users are already registered. Using an IDP allows your users to log in with existing credentials that they already know and use while keeping those user credentials secret from your application.
CyberArk Identity supports OIDC, a single sign-on (SSO) standard that allows you to authenticate users using an existing IDP to provide access to client applications; therefore, CyberArk Identity acts as an OpenID Connect provider (OP).
The following are the terms frequently used in OIDC:
Client: An application, such as a website or a mobile application, that accesses the user information and APIs of CyberArk Identity. Note that the client is not the user. (The user is the person using the client application.)
Client ID: A unique identifier that an authorization service issues to identify a client application. The authorization service generates the client ID when the service registers the application. The authorization service uses the client ID and secret in subsequent API requests to ensure that the client can access an online resource and/or user's information.
Client Secret: A unique code that an authorization service issues when the service registers the application. You can think of it as the password for the client application. The client secret and the client ID enable the client to access an online resource and/or user's information. If you are configuring an implementation with the PKCE Authorization Code Flow, you use code_verifier, code_challenge, and code_challenge_method parameters instead of the client secret in the authorization request.
OpenID Connect Provider (OP): OAuth 2.0 Authorization Server capable of Authenticating the End-User and providing Claims to a Relying Party about the Authentication event and the End-User. In this case, CyberArk Identity acts as the OpenID Provider.
Relying party (RP): OAuth 2.0 Client application requiring End-User Authentication and Claims from an OpenID Provider.
Single Sign-On (SSO): Single sign-on is an authentication scheme that allows users to log in with a single ID to any of several related yet independent websites/ mobile applications. Single sign-on enables users to log in once and access services without re-entering authentication factors.
Claim: Piece of information about the user
Scope: Scopes provide a way to limit access to APIs and user information.
The following diagram illustrates the basic authentication flow. The main actors are the user (resource owner), the RP (client application that the user is accessing), and CyberArk Identity (the OP that acts as an authorization server and the resource server).
- In this example, the user initiates a request through the client application (RP) to start SSO.
- The client application redirects the user to OP, which allows the user to enter credentials.
- The redirection information includes the user's application's client ID, client secret, and the location to go to once the user has successfully authenticated (for example, another screen on your website).
- Upon successful authentication, the OP returns a temporary authorization code to the client application.
- This authorization code is opaque to the client. That is, the client application cannot interpret the authorization code in any way.
- The user's credentials are hidden from the application because the application obtains this authorization code instead of direct client credentials.
- The client application then sends this temporary authorization code back to the OP. The OP then returns the Authorization Token and ID Token that your client application can use to make subsequent API calls.
An OP (for example, CyberArk Identity), also known as an authorization server, provides the following endpoints.
- Authorization endpoint: The OAuth 2.0 authorization endpoint of an IDP authenticates the user and redirects the user to a redirect URI with an authorization code. A client redirects a user to this endpoint to authenticate and authorize the user.
- Token endpoint: The endpoint authenticates a client application and allows it to exchange an access code for the token.
- Userinfo endpoint: The client can use this endpoint to get information about a user once authenticated. This information includes whatever information the user shares in their user configuration.
- end_session_endpoint: The RP requests the CyberArk Identity to log the user out by redirecting the user agent to the end_session endpoint. This URL is obtained via the end_session_endpoint element of the CyberArk Identity's metadata URL or may be learned via other mechanisms.
The RP can request other details such as claims supported by the OP, ID token signature algorithms, default scopes supported, issuer URL etc., using the OP metadata.
The OP metadata is a JSON document containing the OP's endpoint information for a tenant. A client application can use this to configure requests to the OP dynamically. In CyberArk Identity, the OP metadata can be requested using <tenant_url>/<application_id>/.well-known/openid-configuration.
You can also use the /OAuth2/GetMeta API to get the metadata of the application.
This guide provides resources for integrating CyberArk Identity's OIDC protocol with custom apps. The following guides help you to integrate OIDC protocol into your custom application to provide authentication and authorization:
Updated about 2 months ago