Configure AM for client-side OAuth 2.0 tokens
When configured for client-side tokens, AM returns a token (instead of the token reference it returns when configured for server-side tokens) to the client after successfully completing one of the grant flows. For more information about client-side and server-side tokens, see Token storage location.
Enable client-side OAuth 2.0 tokens
These steps configure AM to issue client-side access and refresh tokens:
-
In the AM admin UI, go to Realms > Realm Name > Services > OAuth2 Provider.
-
On the Core tab, enable Use Client-Side Access & Refresh Tokens.
-
Enable Issue Refresh Tokens and/or Issue Refresh Tokens on Refreshing Access Tokens.
-
Save your changes.
-
Configure client-side token denylisting.
For more information, see Client-side OAuth 2.0 token denylist.
-
Configure either client-side token signature or client-side token encryption.
Token signature is enabled by default when client-side tokens are enabled. By default, token signature is configured using a demo key that you must change in production environments.
If you enable token encryption, token signature is disabled, because encryption is performed using direct symmetric encryption.
For more information, see Client-side OAuth 2.0 token encryption and Client-side OAuth 2.0 token digital signatures.
Client-side OAuth 2.0 token denylist
Adding tokens to the denylist prevents client-side tokens from being reused if the authorization code has been replayed, or if tokens have been revoked by either the client or the resource owner.
|
Client-side refresh tokens have corresponding entries in a CTS allowlist, rather than a denylist. When presenting a client-side refresh token, AM checks that a matching entry is found in the CTS allowlist, and prevents reissue if the record does not exist. Adding a client-side OAuth 2.0 token to the denylist also removes associated refresh tokens from the allowlist. |
-
In the AM admin UI, go to Configure > Global Services > OAuth2 Provider.
-
Under Global Attributes, enter the number of denylisted tokens in the Token Denylist Cache Size field.
This cache size determines the number of denylisted tokens to cache in memory, to speed up denylist checks. Enter a number based on the estimated number of token revocations that a client will issue (for example, when the user gives up access or when an administrator revokes a client’s access).
Default: 10000
-
In the Denylist Poll Interval field, enter the interval in seconds for AM to check for token denylist changes from the CTS data store.
The longer the polling interval, the more time a malicious user has to connect to other AM servers in a cluster and make use of a stolen OAuth v2.0 access token. Shortening the polling interval improves the security for revoked tokens but might incur a minimal decrease in overall AM performance due to increased network activity.
Default: 60 seconds
-
In the Denylist Purge Delay field, enter the length of time, in minutes, that denylist tokens can exist before being purged beyond their expiration time.
When client-side token denylisting is enabled, AM tracks OAuth v2.0 access tokens over the configured lifetime of those tokens plus the denylist purge delay. For example, if the access token lifetime is set to 6000 seconds and the denylist purge delay is one minute, then AM tracks the access token for 101 minutes. You can increase the denylist purge delay if you expect system clock skews in an AM server cluster to be greater than one minute. There is no need to increase the denylist purge delay for servers running a clock synchronization protocol, such as Network Time Protocol.
Default: 1 minute
-
Save your changes.
Client-side OAuth 2.0 token encryption
To protect OAuth 2.0 client-side access and refresh tokens, AM supports encrypting their JWTs using AES authenticated encryption. Because this encryption also protects the integrity of the JWT, you only need to configure AM to sign OAuth 2.0 client-side tokens if token encryption is disabled.
-
Go to Realms > Realm Name > Services > OAuth2 Provider.
-
On the Core tab, enable Use Client-Side Access & Refresh Tokens.
-
On the Advanced tab, enable Client-Side Token Encryption.
The alias mapped to the algorithm is defined in the secret stores, as shown in the table below:
Secret ID mappings for encrypting client-side OAuth 2.0 tokens
This table shows the secret ID mapping used to encrypt client-side access tokens:
Secret ID Default alias Algorithms am.services.oauth2.stateless.token.encryptiondirectentestA128CBC-HS256
By default, secret IDs are mapped to demo keys contained in the default keystore provided with AM and mapped to the
default-keystorekeystore secret store. Use these keys for demo and test purposes only. For production environments, replace the secrets as required and create mappings for them in a secret store configured in AM.For more information about managing secret stores and mapping secret IDs to aliases, see Secrets, certificates, and keys.
-
Save your changes.
Client-side OAuth 2.0 access and refresh tokens will now be encrypted.
Client-side OAuth 2.0 token digital signatures
AM supports digital signature algorithms that secure the integrity of client-side tokens.
|
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. |
AM exposes the public key to validate client-side token signatures in its JWK URI. See /oauth2/connect/jwk_uri.
These steps configure the OAuth 2.0 provider to sign client-side tokens:
-
Go to Realms > Realm Name > Services, and click OAuth2 Provider.
-
On the Advanced tab, in the OAuth2 Token Signing Algorithm list, select the signing algorithm to use for signing client-side tokens.
The alias mapped to the algorithm is defined in the secret stores, as shown in the table below:
Secret ID mappings for signing client-side OAuth 2.0 tokens
This table shows the secret ID mappings used to sign client-side access tokens:
Secret ID Default alias Algorithms am.services.oauth2.stateless.signing.ES256es256testES256
am.services.oauth2.stateless.signing.ES384es384testES384
am.services.oauth2.stateless.signing.ES512es512testES512
am.services.oauth2.stateless.signing.HMAChmacsigningtestHS256
HS384
HS512am.services.oauth2.stateless.signing.RSArsajwtsigningkeyPS256
PS384
PS512
RS256
RS384
RS512By default, secret IDs are mapped to demo keys contained in AM’s default keystore and mapped to the
default-keystoresecret store. Use these keys for demo and test purposes only. In production environments, replace the secrets as required and create mappings for them in a secret store configured in AM.For more information about managing secret stores and mapping secret IDs to aliases, see Secrets, certificates, and keys.
-
Save your changes.
Client-side OAuth 2.0 access and refresh tokens will now be signed.