ASP.NET Core 5 with ASP.NET Identity 3.0, I'm using both web pages and apis. I am using OpenIddict to issue a JWT token and to authenticate. My code looks as such:
X509Certificate2 c = new X509Certificate2(@"tokensign.p12", "MyCertificatePassword");
services.AddOpenIddict<WebUser, IdentityRole<int>, WebDbContext, int>()
.EnableTokenEndpoint("/api/customauth/login")
.AllowPasswordFlow()
.UseJsonWebTokens()
.AddSigningCertificate(c);
If I disable UseJsonWebTokens(), I can generate a token and authorise successfully. However, I am not sure that my certificate is validating the returned tokens.
And when enable UseJsonWebTokens, I am able to issue a JWT token at this end point. However, I can't authenticate any request!
I am using the following code in the app configuration:
app.UseJwtBearerAuthentication(new JwtBearerOptions
{
AutomaticAuthenticate = true,
AutomaticChallenge = true,
RequireHttpsMetadata = false,
Authority = "http://localhost:60000/",
Audience = "http://localhost:60000/",
});
app.UseOAuthValidation();
app.UseIdentity();
app.UseOpenIddict();
app.UseMvcWithDefaultRoute();
If I disable UseJsonWebTokens(), I can generate a token and authorise successfully. However, I am not sure that my certificate is validating the returned tokens.
In ASOS (the OpenID Connect server framework behind OpenIddict), there are 2 different built-in serialization mechanisms to create and protect tokens:
Identity tokens (JWT by definition) are always created using this process and you can call UseJsonWebTokens()
to force OpenIddict to issue access tokens that use the same serialization process.
The certificate you specify when calling AddSigningCertificate()
is always used to sign these tokens.
This stack exclusively produces "proprietary" tokens that are not meant to be read or verified by a third-party, as the token format is not standard and necessarily relies on symmetric signing and encryption.
It's the mechanism we use for authorization codes and refresh tokens, that are only meant to be consumed by OpenIddict itself. It's also used for access tokens when you use the default token format.
In this case, the certificate you specify when calling AddSigningCertificate()
is not used.
Instead, these tokens are always encrypted by the Data Protection stack using an Authenticated Encryption
algorithm (by default, AES-256-CBC with HMACSHA256), that provides authenticity, integrity and confidentiality. For that, 2 keys (one for encryption, one for validation) are derived by the Data Protection stack from one of the master keys stored in the key ring.
How can I enforce the request to be validated with my certificate to make sure the JWT token is not tampered with. What are the correct settings that will allow validation and authorisation of my JWT token, given that if I am not using JWT, I am getting authorised successfully.
To answer these questions, it would help if you enabled logging and shared your traces.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With