ClientCertificate authentication (mTLS) / missing cnf value

[CaringDev]

For identifying users by their certificate instead or username / pw we're checking the certificate from the code behind of the "standard" Account/Login index page. If there's a match we sign-in the user:

var user = new IdentityServerUser(...);
user.AuthenticationMethods.Add(OidcConstants.AuthenticationMethods.SmartCard);
this.HttpContext.SignInAsync(user.CreatePrincipal())`;

Then, when the app requests a new access token we get an exception stating that The client certificate in the refresh token request does not match the original used. due to the cnf value not being populated in the original token.

A workaround is to register a ICustomTokenRequestValidator essentially doing request.Confirmation = cert.CreateThumbprintCnf();

Is this how it's supposed to be or is there a better solution?

[AndersAbel]

The cnf claim is used to make a token sender constrained. It should typically refer to a certificate that the client has access to during runtime. The most common scenario is that it is a server side web application and that the certificate belongs to the client application on the server.

I get a feeling here that when client certificates are used to authenticate the user, that triggers code that create mTLS-bound tokens even though that might not be the intention.

Could you please let us know a bit more:

• What flow are you using when logging in? (i.e. what is the AllowedGrantTypes setting for the client?)
• What kind of client application is this? Single Page Application? Server Side Web Application? Native/Mobile app?

[CaringDev]

Thank you for looking into this...
AllowedGrantTypes is GrantTypes.Code for a SPA (using angular-oauth2-oidc).
mTLS bound tokens should be fine for us (if the user presents a cert). We do identify users by their certificate, if any... otherwise redirect to external IdP or local username / PW. Probably we do something fishy here... I'm not saying this is IS' fault :-)

[AndersAbel]

Thank you for the details.

When the token endpoint is called and there is a client certificate on the request, that causes the generated tokens to get a cnf claim. These tokens are bound to the client certificate used when requesting them. APIs should not accept these as bearer tokens, they should require the caller to use mTLS. I guess that your APIs don't support this and simply accepts the tokens as bearer tokens.

Then when you try to use the refresh token, it looks like that request now contains a client certificate, but that it's not the same client certificate as was used when the refresh token was created. Would you be able to somehow validate the thumbprints of the client certificates for the requests to the token endpoint? There should be two requests - the first one during login when the authorization code is exchanged for tokens, the second when the refresh token is used.

If your intention is not to use mTLS-tokens at all but just use mTLS for user authentication I would suggest a workaround by adding a custom token request validator that sets the ProofKeyThumbPrint to null and ProofType to ProofType.None to disable mTLS-bound tokens.