Why is that despite having the .well-known/openid-configuration
specified in dotnet auth settings – we still need to provide the all the information manually?
I my auth flow – the RSA asymmetric encryption is used for JWT tokens and WebAPI application needs to validate the token. JWT is issued by the keycloak
.. The JWT header example:
{
"alg": "RS256",
"typ": "JWT",
"kid": "LSx-RczcXcqiEwgBZuOCcSc91QfNg7u2fnPGDUhzxac"
}
The keycloak provides the realm’s .well-known/openid-configuration
out of the box. It contains the issuer, as well as some other endpoints for data querying. I would also assume that the RSA public key is also publicly discoverable in some way.
The problem is – that it’s not enough to specify the following config in dotnet
builder.Services.AddAuthentication("Bearer")
.AddJwtBearer("Bearer", options =>
{
options.Authority = "http://host.docker.internal:7080/realms/master";
options.MetadataAddress = "http://host.docker.internal:7080/realms/master/.well-known/openid-configuration";
options.RequireHttpsMetadata = false;
};
This code will fail to validate the incoming JWT token and complain about the authority validation failure, as well as signing key validation failure!
The working code is:
string publicKey = "your public key goes here";
var rsa = new RSACryptoServiceProvider();
rsa.ImportSubjectPublicKeyInfo(Convert.FromBase64String(publicKey), out _);
builder.Services.AddAuthentication("Bearer")
.AddJwtBearer("Bearer", options =>
{
options.TokenValidationParameters = new TokenValidationParameters
{
RequireExpirationTime = true,
RequireSignedTokens = true,
ValidateIssuer = true,
ValidIssuer = "http://localhost:7080/realms/master",
ValidateAudience = true,
ValidAudience = "account",
ValidateIssuerSigningKey = true,
IssuerSigningKey = new RsaSecurityKey(rsa),
ValidateLifetime = true,
ValidAlgorithms = new[]
{
"RS256"
}
};
});
It seems counter intuitive to provide the IssuerSigningKey
as well as the ValidIssuer
manually.
To me it looks like all of this information is available in the metadata and the framework should be able to discover and handle it by itself.
Which leads me to believe that I have a fundamentally wrong understanding of either the well-known endpoint purpose or the framework expected logic.
Could someone please clarify what is the correct use-case for the well known endpoint and why the framework is not handling the request validation in a more automated way given that it has a knowledge of the JWT encryption algorithm and the metadata.