OAuth2Provider supports authentication method of client_secret_jwt

[i7a7467]

Description

client_secret_jwt is described in OpenID Connect core. I want to add new authentication method. OpenAM now supports 3 client authentication methods.

• client_secret_basic
• client_secret_post
• private_key_jwt

Solution

I thought about the solution.(while creating sample code)

1. create verifyJwtIdentity for verify client assertion
2. separte the configuration of token endpoint authentication algorithm and id token authentication method algorithm
3. add checking existence of jti value in the case of OpenID Connect
4. add extracting client authentication method from client assertion JWT ( private_key_jwt or client_secret_jwt )

verifyJwtIdentity is also used in other than verifying client assertion. It is used for verifying idtoken in idtokeninfo endpoint. verifyJwtBySharedSecret verify that jwt.aud and client_id are the same. But OpenAM should verify that jwt.aud and token endpoint are the same in the case of client assertion.

Alternatives

Additional context

• Token Endpoint Authentication Method does not work correctly with OAuth2 clients
• id_token_signed_response_alg and token_endpoint_auth_signing_alg are not separated
• OpenID Client authentication with private_key_jwt and client_secret_jwt does not enforce required jti claims
• ForgeRock Access Management 7.x does not support client_secret_jwt (From ForgeRock Documents)

[tsujiguchitky]

Sorry for the delayed response.

1. create verifyJwtIdentity for verify client assertion
2. separte the configuration of token endpoint authentication algorithm and id token authentication method algorithm

verifyJwtIdentity is also used in other than verifying client assertion. It is used for verifying idtoken in idtokeninfo endpoint.

My understanding of this is as follows.

Currently, there is id_token_signed_response_alg in the OAuth Client settings, but there is no token_endpoint_auth_signing_alg. And, id token validation method verifyJwtIdentity() is also used to validate client assertions.

As a result, id_token_signed_response_alg would be used as the algorithm for client assertions.

You mean we should separate id_token_signed_response_alg and token_endpoint_auth_signing_alg.

[i7a7467]

Thanks reply. Yes, my understanding is the same as you.

I recognize that the signing algorithm set in id_token_signed_response_alg is currently only used to determineprivate_key_jwtorclient_secret_jwtas a client assertion. So I thought that I need token_endpoint_auth_signing_alg to check if the signing algorithm was the same as the one set on OpenAM server side. This jira is described that token_endpoint_auth_signing_alg is not necessary, so I was worried if token_endpoint_auth_signing_alg is needed.

[tsujiguchitky]

So I thought that I need token_endpoint_auth_signing_alg to check if the signing algorithm was the same as the one set on OpenAM server side.

I totaly agree.

The Dynamic Client Registration specification says as follows.

token_endpoint_auth_signing_alg

OPTIONAL. JWS [JWS] alg algorithm [JWA] that MUST be used for signing the JWT [JWT] used to authenticate the Client at 
the Token Endpoint for the private_key_jwt and client_secret_jwt authentication methods. All Token Requests using these 
authentication methods from this Client MUST be rejected, if the JWT is not signed with this algorithm. Servers SHOULD support 
RS256. The value none MUST NOT be used. The default, if omitted, is that any algorithm supported by the OP and the RP MAY 
be used.

All Token Requests using these authentication methods from this Client MUST be rejected, if the JWT is not signed with this algorithm.