Multiple secrets per registered client about spring-authorization-server

[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? #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.