ASP.NET Core OIDC/JWT Handlers should not have a direct dependency on the AAD JWT Library

[leastprivilege]

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

Right now, ASP.NET Core has a direct dependency on the AAD JWT library (token handler, token validation parameters etc). This library is primarily driven by its sponsor - the AAD team.

There are more JWT options in .NET - being able to plug in a different JWT implementation would be beneficial for the .NET ecosystem.

Describe the solution you'd like

ASP.NET Core should own its main JWT validation abstractions and rather ship with an by-default integration with the preferred JWT library. If that is the "in-house" one - fine. But it should be possible to plug in different implementations - similar to the DI system.

Additional context

AzureAD/azure-activedirectory-identitymodel-extensions-for-dotnet#1687 (comment)

AzureAD/azure-activedirectory-identitymodel-extensions-for-dotnet#1574

AzureAD/azure-activedirectory-identitymodel-extensions-for-dotnet#1516

https://twitter.com/ycrumeyrolle/status/1431544530357075968

[davidfowl]

@leastprivilege would you like to write up an API proposal for these APIs? That will help kick start the process and also help us better understand the scope of the work.

[Tratcher]

The current auth handlers are very thin wrappers around the IdentityModel libraries and have little additional functionality. What benefit do you get from abstracting the IdentityModel layer vs providing alternative auth handlers?

I expect you'd want different types in the options which isn't something that abstracts well.

[davidfowl]

Which is why I think a concrete API proposal would be a great starting point

[brockallen]

The current auth handlers are very thin wrappers around the IdentityModel libraries and have little additional functionality. What benefit do you get from abstracting the IdentityModel layer vs providing alternative auth handlers?

I think the concern is that the current JWT library that's mainly for AAD has a poor track record of quality, consistency, and breaking changes, and it would be nice to be able to not use it.

[kevinchalet]

As @leastprivilege and @brockallen said, the main problem is that IdentityModel is exclusively driven by AAD's needs, with close to zero consideration for the third-party projects that depend on it (e.g IdentityServer or OpenIddict). Sensitive things like AAD-specific telemetry being added to the metadata retrieval feature or the deprecation of the Validate* options in TokenValidationParameters are not even discussed with the community.

That said, I'm not sure this situation is specific to the IdentityModel project: lately, even the ASP.NET team hasn't really been interested in gathering feedback from community members/projects prior to introducing new changes. The situation even got worse with the adoption of the "monorepo" approach, that makes monitoring topics you're interested in - and thus sending spontaneous feedback - almost impossible 🤷🏻

[davidfowl]

Thanks for that feedback @kevinchalet, if this issue turns into more than just an API proposal then I'm inclined to move it to the discussions milestone.

[veikkoeeva]

I concur. I tried the JWT tokens quickly as a prototype at https://github.com/lumoin/Verifiable and removing soon all the last traces. Mostly also my concerns are recorded here or in the links. Maybe relevant to think if .NET should be the owner and not ASP.NET. Noting also that web safe Base64 encoder in .NET could be nice.

[davidfowl]

Maybe relevant to think if .NET should be the owner and not ASP.NET. Noting also that web safe Base64 encoder in .NET could be nice.

I was thinking the same thing. It's possible this should just be an API proposal on the dotnet/runtime repo. I'm not sure it needs to be an abstraction then, maybe it should just be a core part of the libraries that implement the spec and use System.Text.Json as the implementation.

@leastprivilege does that sound like a good idea? If so, can you close this issue and create an issue on dotnet/runtime with the API proposal template?

[blowdart]

I've been mulling this since the proposed changes from AAD last week, thinking about it in terms of how we abstracted json away and provided a reference implementation.

At its bare minimum what is needed is just JwtValidator/Parser with a single method Validate/Parse, which returns the information needed. But I don't think that simple an implementation is flexible enough -

1. We can view a jwt as made up of three things, the header, the payload and the signature, all of which are part of a single string. Whilst in general most folks care about the claims in the payload and nothing more, it would make sense an optiolnal results object to contain all three sections of the token, so we'd end up with JwtValidationResult class which might be returned from a Parse method, which also includes a boolean of IsValid()
2. Users may want to know why a parsed JWT is invalid, so, like X509Validation, a collection of JwtValidationErrors could be useful.
3. ASP.NET takes claims and turns them into a principal which is treated like a User. But JWT can be used to encapsulate more than just a user. one question is would it be up to ASP.NET to transform the validation results into a Principal from the claims collection, or does that belong in the Validator/Parser?
4. Do we want to go further, and allow creation of Jwts from the base classes? That becomes more complicated, because if we allow creation, do we support producing the right type of metadata endpoint contents for key publication etc,.? Personally, I'd say no to this, we'd want to go as simple as possible here, and creation of new tokens is beyond simple.
5. Finally, do we create our own lightweight parser/validation in runtime to sit alongside the rest of the security classes? If so that has risks around getting it right and patching, and down-level support (would we package it as a nuget package for older .NET versions - by which I mean 6.0, rather than, say, Framework). We'd want to consider where its boundaries lie, given that the associated standards around jwt keep growing and branching. I'm not sure we'd want to play catchup.

Configuration of the actual parser should be opaque to any parsing functions, so a parser can decide on all those contentious things, like claims mapping, metadata retrieval, refreshing of cached keys etc. Keeping the actual mechanics opaque would allow for alternative classes to start supporting things the community has wanted for quite a while like encrypted JWTs without consumers having to change code, but should we look at some base events, or callbacks much like Json.Net did or does that fall to a consumer like asp.net to expose?

As for @veikkoeeva's comment on encoding, that's separate, I'd suggestion that becomes an issue in the runtime repo all its own and linked to the existing encoding classes.

Anyway, these are random thoughts, dropping from my head over the last week, and gathered on an early Sunday as I drink the first coffee of the day, so they're by no means anything well designed, or complete, but thoughts for further discussion.

[veikkoeeva]

@blowdart Let I do the same on my evening coffee... I could add one more and that is flexibility of choosing one's library to sign, validate and encrypt. The AAD one doesn't make it easy while also not providing much options either (one could say the hierarcy feels fairly rigid). It would be nice to have have a clear way to choose one's preferred library due to concerns such as:

• BouncyCastle/NSec is approved and mandaged in some organization X. So it needs to be used if not something that's straight from the official .NET supply-chain.
• Wanting to cross-test or develop other libraries.
• Choosing platform dependent way something, say something that works well in browser and WASM environment.
• Using specialized hardware: TPMs, HSMs, TEEs...

I have currently a shim (test showing here, also will be properly named and not just tuples at some point) for NSec, BouncyCastle and at some point for .NET and TPM ones too. And looking how to best do some of this JWT stuff. Maybe I'd like to make a note, partially related to hardware that having a new byte[] in somewhere in the guts of a library that has sensitive bytes there may make people, say, in payments, wonder if it's worth coming up mitigations or do something else (as that code shows, I'm mitigating it with prototyping a sensitive boundary wrapped, so that could consider TPMs, AES encryptinh memory, whatever). Maybe performance related issues too there.

I concur about that encoding. Goes to show there are many issues within many issues.

[blowdart]

Oh dear lord let's not reinvent secure string 😂

Jwt creation is interesting. I'm not sure it's a key scenario for a lot of folks, that tends to be for token servers rather than a mainline scenario for the majority of users. I'd worry that would overcomplicate a parsing abstraction.

[kevinchalet]

As for @veikkoeeva's comment on encoding, that's separate, I'd suggestion that becomes an issue in the runtime repo all its own and linked to the existing encoding classes.

• Support Base 64 URL runtime#1658
• URL and filename safe base64 encoding runtime#31099