Security Authentication handlers should not reference JwtSecurityToken

[brentschmaltz]

Is your feature request related to a problem? Please describe.

A clear and concise description of what the problem is.
Example: I am trying to do [...] but [...]

Describe the solution you'd like

Asp.net uses ISecurityTokenValidator.ValidateToken which has an out parameter of type SecurityToken. asp.net assumes a JwtSecurityToken.
If a user plugs in a different ISecurityTokenValidator that returns a different valid token that represents a JWT, this will fail.

Here for OIDC

also here (there are others)

asp.net and IdentityModel will need to work together to develop the correct JWT abstractions so new token validators, handlers and tokens can be used.

see: IdentityModel AzureAD/azure-activedirectory-identitymodel-extensions-for-dotnet#1349

Additional context

Add any other context or screenshots about the feature request here.

[blowdart]

@Tratcher for your consideration.

However as we only support JWT (and WSFED) I don't know if I'm too concerned right now.

@brentschmaltz What other tokens are you expecting? JWE?

[brentschmaltz]

@blowdart We have invested in JsonWebToken / JsonWebTokenHandler where we have the following improvements.

1. Performance ~10%
2. No mapping of claimtypes
3. No reference to Newtonsoft

We are thinking an abstraction for JWT's, so that a JwtTokenHandler will return an IJwtToken or JwtToken (abstract).
Right now we are linked to a specific implementation that we are not investing in anymore.

In addition, CBOR is a variation of JWT's that are helpful in the IOT environment as the size is minimized.

Hope this helps.

[blowdart]

You know we're adding CBOR to the framework right?

[brentschmaltz]

@blowdart I did not know that, we have started a handler similar to JsonWebTokenHandler.
Where is this work taking place, we probably don't need two.

[blowdart]

Now, @bartonjs is doing it.

[brentschmaltz]

@bartonjs @blowdart cbor is essentially an encoded json token.
Where are you planning on shipping it?

[blowdart]

In 5. We need it for passwordless/FIDO2 support

[brentschmaltz]

@blowdart I guess we will have two then, we need it to seamlessly plug into our authz/authn model.

[bartonjs]

@brentschmaltz I'm expecting that we'll ship it as a netstandard2.0 NuGet package, though there are a few political hurdles (that are easier if you would be a consumer of that package).

[leastprivilege]

• I have never seen anyone use the OIDC handler with an alternative JWT validator
• If you want to decouple them, then the OIDC handler should own the validation parameters type as well as the interface - the validator would return ClaimsPrincipal.

I never thought this "abstraction" with the interface was useful.

[brentschmaltz]

@bartonjs for IdentityModel to use any token type it must fit into our model of Token / TokenHandler / ClaimsIdentity trio. We have SecurityToken and TokenHandler are the base class for those.

@leastprivilege OIDC is special in that the specification defines that a JWT is the token type. I am exactly sure what "abstraction" you are referring to, but there are multiple options.

Moving to a SecurityToken or JToken abstraction will allow us to do things like remove dependency on System.IdentityModel.Tokens.Jwt which has issues of dependency on Newtonsoft, performs claim-type mapping, is slower than JsonWebToken.

We need to continue to support numerious runtimes, with out a proper abstraction it is difficult to include improvements such as system.text.json and take advantage the new string features with out cluttering up the code with #if defs and multiple targets.