JwtBearer does not return any useful info when failing to validate/accept a token

[vibronet]

It is currently very challenging to troubleshoot validation failures originated in the JwtBearer middleware. The client doesn't get back the reasons for which the token failed the validation, which makes it very tough to identify common error situations (such as audience mismatch, untrusted issuers, and so on).
I suggest that the JwtBearer middleware should return some indication about the failure in the response, and specifically in the WWW-Authenticate header.
It goes without saying that the kind of information returned should undergo rigorous security reviews to ensure that the middleware does not leak information that could be used for refining an attack against the protected service.

[Tratcher]

@blowdart

[Tratcher]

The first problem is getting meaningful errors out of ValidateToken. See AzureAD/azure-activedirectory-identitymodel-extensions-for-dotnet#312.

[blowdart]

If we can get the information then we should return it somehow.

[Eilon]

Need to get a grasp on what the top hard-to-debug/hard-to-diagnose issues are.

Some problem areas:

• Audience mismatch
• Issuers that the app doesn't like
• Tokens outside of valid window (e.g. expired, not yet valid)
• Signature failures (e.g. key not found)

Some of these already have specific exceptions associated with them.

[Eilon]

Should look into what's valid in the WWW-Authenticate header to transmit the diagnostic message. http://www.ietf.org/rfc/rfc2617.txt

[kevinchalet]

Definitely a good idea (FWIW, we'll implement a similar thing in the aspnet-contrib validation and introspection middleware in the next version).

That said, it might be interesting to provide an option to turn off these details, for people who don't want to disclose them (we had a similar discussion with @MonkeyJamboree about ASOS' introspection endpoint, and whether we should tell the caller why the token was invalid: aspnet-contrib/AspNet.Security.OpenIdConnect.Server#157)

[Eilon]

@PinpointTownes good point!

[Eilon]

@brentschmaltz can you add a comment here with which exceptions are thrown for the cases we are concerned about?

[Eilon]

Ping @brentschmaltz

[Tratcher]

Problem	Exception
Audience mismatch	SecurityTokenInvalidAudienceException
Issuers that the app doesn't like	SecurityTokenInvalidIssuerException
Tokens outside of valid window (e.g. expired, not yet valid)	SecurityTokenNoExpirationException, SecurityTokenInvalidLifetimeException, SecurityTokenNotYetValidException, SecurityTokenExpiredException
Signature failures (e.g. key not found)	SecurityTokenInvalidSignatureException, SecurityTokenSignatureKeyNotFoundException

Anything else we should be reporting to users @brentschmaltz @vibronet?