Understanding Signing Key Configurations and Shadow Keys in FusionAuth JWTs | FusionAuth Forum

Your browser does not seem to support JavaScript. As a result, your viewing experience will be diminished, and you have been placed in read-only mode .

Please download a browser that supports JavaScript, or enable it if it's disabled (i.e. NoScript).

Understanding Signing Key Configurations and Shadow Keys in FusionAuth JWTs

Scheduled

Pinned

Locked

Moved

Solved

Frequently Asked Questions (FAQ)

hosting

645

Loading More Posts

Oldest to Newest

Newest to Oldest

Most Votes

Reply

Reply as topic

Log in to reply

This topic has been deleted. Only users with topic management privileges can see it.

wesley

last edited by

The tenant configuration under JWT allows ID tokens and access tokens to be signed with different keys. What is the use case for this, and are there any best practices?

Additionally, the "shadow keys" use the client_secret as the signing key and are permitted only for the id_token , not the access_token . What is the use case for this, and are there any best practice considerations?

1 Reply<br>Last reply

Reply<br>Quote

wesley

@wesley

last edited by

Different Signing Keys for ID and Access Tokens :

Configuring different signing keys for ID tokens and access tokens is an edge case, typically used when specific requirements exist:

Use Case :

Access tokens may need to be signed with HMAC for speed, particularly if they are consumed by resource servers within a controlled environment.

ID tokens might require RSA signing to ensure security since they are often handled by clients that cannot be fully trusted.

Rotating keys independently for ID and access tokens might be necessary to meet compliance or security policies.

Best Practice :

Unless you have a clear requirement for different key configurations, it's generally unnecessary to use separate keys. A unified approach simplifies key management and reduces potential issues.

Shadow Keys (client_secret as Signing Key) :

Shadow keys are primarily included to ensure compliance with OpenID Connect (OIDC) specifications.

Use Case :

The client_secret as a signing key is used for ID tokens to meet OIDC compliance requirements. However, it’s not allowed for access tokens since access tokens are designed to be more flexible and are often consumed outside of the client-server context.

Best Practice :

This feature is useful only for OIDC-compliant setups where such signing methods are mandated. If OIDC compliance is not a requirement, shadow keys and their configurations are likely unnecessary.

Summary :

Both features—different signing keys and shadow keys—are provided to accommodate specific compliance or architectural requirements. For most use cases, these options are not needed unless dictated by your organization's security policies or external compliance requirements.

1 Reply<br>Last reply

Reply<br>Quote

W wesley marked this topic as a question on

W wesley has marked this topic as solved on

First post

Last post

Go to my next post

Looks like your connection to FusionAuth Forum was lost, please wait while we try to reconnect.