Multiple secrets per registered client

[jworner]

Expected Behavior Please add support for multiple client secrets for better client secret rotation and usage.

This request is for a new feature to allow multiple client secrets to be active at the same time for each client. Preferably, each client secret should have a name, description, and expiration.

For example, this implementation already exists in Azure.

Use-cases:

• A common security requirement is to regularly rotate client secrets. The current implementation carries operational risk because the old client secret will no longer work immediately, but the gap of updating the secret may cause issues. Having multiple client secrets with respective expiry ensures sufficient time to issue a new client secret and update in client applications.

• This implementation also allows issuing client secrets to developers for local or troubleshooting scenarios without compromising actual client secret used in deployed environments

Current Behavior The current implementation supports only one secret per registered client.

Context There is no workaround.

[jgrandja]

@jworner I haven't seen anywhere in the specs where an Authorization Server MAY support multiple client_secret's per client registration. This seems like a proprietary implementation in Azure. I believe this capability belongs in the consuming application, instead of the framework code.

Furthermore, it's recommended to use either private_key_jwt or tls_client_auth (even self_signed_tls_client_auth) for production deployments as those methods are far more secure then client_secret_basic. Additionally, those methods inherently support key rotation. FYI, private_key_jwt has been supported since 1.0 and tls_client_auth and self_signed_tls_client_auth is being released in the upcoming 1.3 release.

I'm going to close this as I don't believe this capability is defined in any of the specs. If you're able to provide me a link to a spec defining this capability, then we'll consider re-opening this for further discussion. Regardless, I would recommend using private_key_jwt, tls_client_auth or self_signed_tls_client_auth.

[konstantinj]

Hi @jgrandja just came across this for the same reason. Using private_key_jwt sounds like a good idea. Unfortunately I can't find any documentation how to use it. I guess there is none yet? https://github.com/spring-projects/spring-authorization-server/issues/781

I do not understand where to handle the keys for each client.

[jgrandja]

@konstantinj See gh-781 as it provides a link to a branch with a working sample configuration. I just rebased that branch on main so it's up-to-date. We'll add the How-to guide in the next release.

[konstantinj]

@jgrandja thanks, this is the configuration on the client side? I was looking for the components that are missing on server side like the JWKS storage and a reference implementation to push the keys to that storage.

[jgrandja]

@konstantinj Please take the time to review the sample. It's a complete sample with both client and authorization server configuration demonstrating the client_credentials grant flow.

I was looking for the components that are missing on server side like the JWKS storage

The JWK used to sign the client_assertion comes from the JWKSource stored on the client side NOT the authorization server side.

You can review JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants to see how private_key_jwt client authentication works.

[konstantinj]

@jgrandja I think I got it now. The client is offering the /jwks endpoint for the server to fetch the pub key for validation so the server does not need to store any certificates?