josephdecock
commented
1 year ago IdentityServer enforces that the subject, issuer, and client_id all match, because the semantics of our secret validation is that we want the client application to prove that it possesses a cryptographic secret. We do that by having the client sign a token with a private key and validate it using its public key. We don't have a mechanism for establishing trust with a third party that might issue tokens on behalf of the client. This does go beyond what is explicitly required by the specification, but the spec also says that implementations are allowed to add their own rules:
Application of additional restrictions and policy are at the discretion of the authorization server.
We require the jti claim because we use it to perform replay detection. While the spec says that tokens "MAY" include jti (MAY making it optional, so that spec-compliant implementations could accept a token without one), it also says that authorization servers may use the jti to do replay detection, as we do. Since we've decided to do so, we add the restriction that the jti must be present.
If you want different behavior, you can implement your own ISecretValidator. All of the behavior that I'm describing above is implemented in the PrivateKeyJwtSecretValidator (which implements that interface). You could create your own implementation of the ISecretValidator that didn't do replay detection and so didn't require the jti and that trusted jwts issued by some other issuer. Then just register the validator with DI. The way that the validation works, if any validator is able to validate, then the secret is trusted, so the existing validator not being able to validate shouldn't be an issue. I suppose it might waste resources, so if you wanted to you could avoid registering the validator in the first place. It gets registered by the AddJwtBearerClientAuthentication. Under the covers, that method is just registering a few things in DI. You could do that yourself, but leave out the validator you don't want:
// This is the IdentityServer method
public static IIdentityServerBuilder AddJwtBearerClientAuthentication(this IIdentityServerBuilder builder)
{
builder.AddSecretParser<JwtBearerClientAssertionSecretParser>();
builder.AddSecretValidator<PrivateKeyJwtSecretValidator>();
return builder;
}
// So do this instead of a call to AddJwtBearerClientAuthentication
builder.AddSecretParser<JwtBearerClientAssertionSecretParser>();
builder.AddSecretValidator<YourSecretValidator>(); // TODO, create your secret validator class
b3n3d17
hannestschofenig
brockallen
AndersAbel
Which version of Duende IdentityServer are you using? v6
Which version of .NET are you using? dotnet --version 7.0.400
Describe the bug
The private key JWT validation logic rejects my authentication request. Here the 2 screenshot of the relevant error messages:
To Reproduce
Expected behavior
I expect the validation logic to accept my Token even though subject and issuer are not equal and i do not have a JTI.
Additional context
Hi, i am trying to use k8s serviceaccount token projection to authenticate my microservice.
However, the provided Token Validation logic is stricter than required by [RFC7523 - Section 3](https://datatracker.ietf.org/doc/html/rfc7523#secti
on-3). Therefore, the authentication fails.
Dudende Identiy Server v6 checks for a JTI and it enforces the issuer to be the same as the client_id. Both checks are not required by the RFC (as far as I can read at least). I would like to have a "setting" which would facilitate only the minimum required checks. Currently I do not see any obvious way to change that behavior. Am I missing something obvious here?
I am using the following configuration:
And the following client configuration.
Here a token which I manipulated to be accepted
Here the token which k8s actually provides me
Thank you for your help