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.
