Instead of providing the parameters for an authorize request as individual query string key/value pairs, you can package them up in signed JWTs. This makes the parameters tamper proof and you can authenticate the client already on the front-channel.
See here for a sample for using signed authorize requests (and JWT-based authentication) in ASP.NET Core.
You can either transmit them by value or by reference to the authorize endpoint - see the spec for more details.
Duende IdentityServer requires the request JWTs to be signed. We support X509 certificates and JSON web keys, e.g.:
var client = new Client
{
ClientId = "foo",
// set this to true to accept signed requests only
RequireRequestObject = true,
ClientSecrets =
{
new Secret
{
// X509 cert base64-encoded
Type = IdentityServerConstants.SecretTypes.X509CertificateBase64,
Value = Convert.ToBase64String(cert.Export(X509ContentType.Cert))
},
new Secret
{
// RSA key as JWK
Type = IdentityServerConstants.SecretTypes.JsonWebKey,
Value = "{'e':'AQAB','kid':'...','kty':'RSA','n':'...'}"
}
}
}
If the request_uri parameter is used, IdentityServer will make an outgoing HTTP call to fetch the JWT from the specified URL.
You can customize the HTTP client used for this outgoing connection, e.g. to add caching or retry logic (e.g. via the Polly library):
builder.AddJwtRequestUriHttpClient(client =>
{
client.Timeout = TimeSpan.FromSeconds(30);
})
.AddTransientHttpErrorPolicy(policy => policy.WaitAndRetryAsync(new[]
{
TimeSpan.FromSeconds(1),
TimeSpan.FromSeconds(2),
TimeSpan.FromSeconds(3)
}));
Request URI processing is disabled by default. Enable on the Endpoints on the IdentityServerOptions. Also see the security considerations from the JAR specification.
You can access the validated data from the request object in two ways: