Use principal claims if the AT claims are unavailable

[jpda]

We were using this before it was packaged into a library (thanks!) and now we're integrating this library and dropping most of the original code.

AccessTokenClaims on DPoPProofValidationContext is empty, causing the new lookup for cnf to fail in `ValidateHeader.'

The DPoPJwtBearerEvents.TokenValidated event is parsing the AT with a JsonWebTokenHandler, but we have encrypted JWTs which produces an empty array and causes the `DPoPValidation.

Since we are in the TokenValidated event, can we default to (or fall back to) the context's Principal claims? At that point the token has been decrypted and validated by the Jwt handler as we'd expect. Using context.Princpal.Claims works as expected, with the original claims from our AT.

Alternatively we could use handler.ValidateToken(TokenValidationParameters) but that would require us to re-configure our validation params to include the decryption key resolver, which seems duplicative.

I personally do not know of a reason why the context claims would be untrustworthy, particularly since handler.ReadJsonWebToken does no validation on the AT.

for example (from DPoPJwtBearerEvents.cs):

// TODO - Add support for introspection
var handler = new JsonWebTokenHandler();
var parsedToken = handler.ReadJsonWebToken(at);

var result = await _validator.Validate(new DPoPProofValidationContext
{
    Scheme = context.Scheme.Name,
    ProofToken = proofToken,
    AccessToken = at,
    // get the context claims here
    AccessTokenClaims = context.Principal?.Claims ?? parsedToken.Claims ?? [],
    Method = context.HttpContext.Request.Method,
    Url = context.HttpContext.Request.Scheme + "://" + context.HttpContext.Request.Host + context.HttpContext.Request.PathBase + context.HttpContext.Request.Path
});

thanks!

[josephdecock]

Thanks again for raising this! Great idea to use the context claims.