Access tokens

Access tokens are credentials that are used to access protected resources. They are used in token-based authentication to allow access to a set of APIs. The access tokens can be opaque or JWT tokens. CyberArk Identity, by default, supports JWT access tokens in the OpenID Connect application.

Once the user is authenticated, the client application requests the CyberArk Identity for access tokens. The access token is sent as a bearer token for the subsequent API calls. The access to the CyberArk Identity APIs or the custom app APIs can be limited using scopes.

❗️

This is an early access feature for the OpenID Connect custom app. Please get in touch with your administrator to enable this feature.

Structure of access token

The access token generated by CyberArk Identity has the below structure:

{
  "auth_time": 1661741241,
  "iss": "{tenant_url}/{application_id}/",
  "iat": 1661747156,
  "aud": "<client_id>",
  "unique_name": "<username>",
  "exp": 1661765156,
  "sub": "<user_uuid>",
  "nonce": "abc",
  "scope": "<scope>"
}

The fields of the access token can be described as below:

Access token validation

An access token is meant to be used for API calls. Once the client application receives the access token, the following verifications can be done as below:

• The access Token generated by CyberArk Identity is a JWT token encrypted using the "RS256" algorithm. This value can be found in the id_token_signed_response_alg parameter that can be found in the metadata of the OIDC app. The client must validate the signature of the access Token according to JWS using the algorithm specified in the JWT alg Header Parameter.

• The client must use the JWT keys provided by the issuer. The JWT keys are shared with the client using the metadata URL. The client can request the keys by sending an API call as below:

POST {tenant_url}/OAuth2/Keys/{application_id}

• The Issuer Identifier for the OpenID Provider (typically obtained during Discovery) must match the iss (issuer) claim's value.
• The client must validate that the aud (audience) Claim contains its client_id value registered at the issuer.
• The current time must be before the time represented by the exp Claim.
• The iat Claim can be used to reject tokens issued too far away from the current time, limiting the amount of time that nonces need to be stored to prevent attacks. The acceptable range is client specific.
• If a nonce value was sent in the Authentication Request, a nonce Claim must be present, and its value checked to verify that it is the same value as the one sent in the Authentication Request. The client should check the nonce value for replay attacks. The precise method for detecting replay attacks is client specific.
• The client should check the auth_time Claim value and request re-authentication if it determines that too much time has elapsed since the end-User authentication.

The client can also check if the access token is still valid by making either of the following requests to CyberArk Identity:

• Use the introspect endpoint to get the token's active status
• Use the /Security/whoami endpoint passing the code as a Bearer in the Authorization header. The Result field in the response contains information about the user authorized on the tenant using the specified token, which implies that the token is valid.

Storing access tokens

The most secure way to store the access tokens is on the server side for web applications and SPAs. The problem with this approach is SSO will not be supported, and the user needs to re-authenticate every time.

Another possible approach would be to store the access tokens as a cookie using the set cookie. Issues with this approach are XSS attacks and CSRF attacks.

• In XSS attacks, the client-side JS can read the cookies. This can be mitigated by setting the cookie as httpOnly cookie.
• In CSRF attacks, the cookies are sent to the attackers. This type of attack can be mitigated using CORS policy, X-CSRF-TOKEN, or the same site cookie.

Storing the access token in local or session storage is prone to XSS attacks. Besides, any data in sessionStorage is erased when a tab or a window is closed, so the user will have to log in every time to close and reopen tabs or the browser window.

For native mobile apps, store tokens in the OS's secure storage and limit access to that storage. For example, leverage KeyStore for Android and KeyChain for iOS.

👍

CyberArk Identity SDKs to store tokens

CyberArk Identity Android and iOS SDKs provide methods to store tokens in secure storage. Please find the links below to store tokens:

Access token expiry

The admin can set the access token expiry on the OIDC custom app as below:

The default value is 5 hours.

It is recommended to have short-lived access tokens. To renew the access tokens, you must re-authenticate the user using CyberArk Identity or the refresh token to get a new access token without re-authenticating the user.