Sharing JWK Sets Across Multiple Applications

Q: Can multiple applications share a single JWK (JSON Web Key) set for token validation?

(Keywords: OIDC, OAuth 2.0, JWK Set, Identity Provider, Token Validation, Multi-Application Architecture)

A: Yes, absolutely. In fact, sharing a single JWK set across multiple applications is not only possible but is considered the standard best practice under OpenID Connect (OIDC) and OAuth 2.0 frameworks.

Why does this work?

The JWK Set is tied to the Issuer (the Identity Provider, such as a Keycloak Realm or Google), not to the individual Client Application. Because the Identity Provider (IdP) uses the same private key(s) to sign tokens for a specific realm/scope, all applications within that scope must use the same corresponding public keys to verify them3333.

How the Mechanism Works:

1. Centralized Publishing: The IdP publishes all active public keys at a single, public URL endpoint known as the jwks_uri.

2. Auto-Discovery: Applications (or the digiRunner gateway) automatically discover this endpoint using the IdP's "Well-Known" URL (e.g., /.well-known/openid-configuration), eliminating the need for manual key configuration.

3. Token Verification: When a backend service receives a token, it looks at the kid (Key ID) in the token header, fetches the shared JWK Set from the jwks_uri, and uses the matching public key to verify the signature.

Real-World Examples:

• Keycloak: If you have a Realm (e.g., customer-api-realm), it exposes one specific jwks_uri. Whether you have 5 or 50 different clients (APIs) in that realm, they all validate tokens using that single URL.

• Google: All applications globally that integrate with Google Sign-In verify tokens using the same global Google JWK Set.

Key Benefits:

• Centralized Management: The IdP handles key rotation automatically without requiring changes in your applications.

• Simplified Configuration: You only need to configure the IdP's Issuer URL; the system handles the rest.

• Enhanced Security: Relies on standardized, vetted verification protocols rather than custom key exchange methods.