PingOne Advanced Identity Cloud

Client-side tokens

By default, Advanced Identity Cloud returns a token to the client after successfully completing one of the OAuth 2.0 grant flows.

This example shows the encoded client-side token as a value of the access_token property:

{
   "access_token":"eyJ0eXAiOiJKV1QiLOT05FIiwiYWxnQY1lIjoxNTM5MDEzMzYyLsbSI6Ii8iLCj...",
   "scope":"write",
   "token_type":"Bearer",
   "expires_in":3599
}

An access token contains a large amount of information about the user, permissions, validity, and so on. You can see the information when the token is decoded.

Example decoded access token
{
     typ: "JWT",
     zip: "NONE",
     alg: "HS256"
}
{
     sub: "(usr!myClient)",
     subname" "myClient",
     cts: "OAUTH2_STATELESS_GRANT",
     auditTrackingId: "f20f4099-5248-4399-a7f0-2d54d4020099-108676",
     iss: "https://<tenant-env-fqdn>/am/oauth2",
     tokenName: "access_token",
     token_type: "Bearer",
     authGrantId: "1LUgI8zcDWqcfEnnLdZDnNqA2wc",
     aud: "myClient",
     nbf: 1539075967,
     grant_type: "client_credentials",
     scope: [
      "write"
     ],
     auth_time: 1539075967,
     realm: "/alpha",
     exp: 1539079567,
     iat: 1539075967,
     expires_in: 3600,
     jti: "FTQT6eZkDhm6PHEaSthORoTLB80"
}
[signature]

Client-side token characteristics

  • Client-side tokens are larger than the reference returned for server-side tokens.

    If you send client-side tokens in a header, pay attention to their size. The size of the token can’t exceed the maximum header size allowed by your end users' browsers.

    The size of a token increases when you customize Advanced Identity Cloud to store additional attributes in tokens.

  • Client-side tokens are presented to the client after successfully completing an OAuth 2.0 grant flow, which makes them vulnerable to tampering attacks.

    Configure Advanced Identity Cloud to sign and encrypt them to mitigate this risk.

  • Client-side tokens can be introspected without calling the authorization server.

  • They incur an overhead when they’re decrypted and verified because Advanced Identity Cloud doesn’t store the decrypt sequence of the token in memory.

  • Client-side tokens support token denylisting.

    Advanced Identity Cloud maintains a list of revoked tokens and authorization codes stored in the CTS token store. Token denylisting protects against replay attacks and is always enabled for client-side tokens.

    When a client presents a client-side token in a request, Advanced Identity Cloud checks whether the token has been revoked in the CTS token store. If the token hasn’t been revoked, Advanced Identity Cloud decrypts the token to retrieve its information.

    • Advanced Identity Cloud periodically polls the CTS for changes to logged-out sessions. There is a small window during which the CTS might not be updated with the latest denylisted client-side tokens. If this window isn’t acceptable in your deployment, use server-side tokens instead.

    • Client-side refresh tokens have corresponding entries in a CTS allowlist rather than a denylist. When presenting a client-side refresh token, Advanced Identity Cloud checks that a matching entry is found in the CTS allowlist, and prevents reissue if the record doesn’t exist.

      Adding a client-side OAuth 2.0 token to the denylist removes the associated refresh token from the allowlist.

Protect client-side tokens

To protect OAuth 2.0 client-side access and refresh tokens, Advanced Identity Cloud supports encrypting their JWTs using AES authenticated encryption. Because this encryption also protects the integrity of the JWT, you only need to configure Advanced Identity Cloud to sign client-side tokens if token encryption is disabled.

Client-side tokens must be signed and/or encrypted for security reasons. If your environment does not support encrypting OAuth 2.0 tokens, you must configure signing to protect them against tampering.

Encrypt tokens

To configure the OAuth 2.0 provider to encrypt client-side and refresh tokens:

  1. Under Native Consoles > Access Management, go to Realms > Realm Name > Services > OAuth2 Provider.

  2. On the Advanced tab, enable Encrypt Client-Side Tokens.

  3. Save your changes.

    Client-side OAuth 2.0 access and refresh tokens will now be encrypted.

When you enable token encryption, token signature is disabled because Advanced Identity Cloud encrypts tokens using direct symmetric encryption.

Sign tokens

Advanced Identity Cloud secures the integrity of client-side tokens by signing them with digital signature algorithms.

Token signature is enabled by default for client-side tokens, using a demo key. You must change this key in production environments.

Advanced Identity Cloud exposes the public key to validate client-side token signatures in its JWK URI (/oauth2/connect/jwk_uri).

To configure the algorithm used to sign client-side tokens:

  1. Under open_in_new Native Consoles > Access Management, go to Realms > Realm Name > Services.

  2. Select OAuth2 Provider and click the Advanced tab.

  3. In the OAuth2 Token Signing Algorithm list, select algorithm to use for signing client-side tokens.

  4. Save your changes.