Understanding Signing Key Configurations and Shadow Keys in FusionAuth JWTs

[wesley]

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?

[wesley]

1. 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.
2. 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.