FakeAuth doesn't know how to do JWT bearer tokens

[floyd-may]

For apps that use JWT Bearer token authentication (SPAs e.g.) doing end-to-end testing using FakeAuth poses a problem since it would require adding an X-FakeAuth-Claims header as an alternative method of authentication within the SPA. I think FakeAuth should be able to (optionally, disabled by default) accept a JWT and construct a principal based on the claims in it. That way e2e tests can construct a JWT and put it into the browser's localStorage (or similar) to authenticate.

And before you ask, yes, I'm willing to build it 😉

[calebjenkins]

Apologies for the delayed response @floyd-may (I've been heads down with a new role). Have you looked at Fake Authentication JWT Bearer implementation? I'm curious how this would be different? The whole point of FakeAuth was to be auth agnostic by injecting itself directly into the asp.net pipeline, but I get that doesn't address integration tests. It's def worth discussing.

Full transparency, I'm still digging in to JWT details and how that compares to OAuth we would get from something like Okta. My experience is that from an architectural perspective they are the same - and things like Okta/Msft Identity and Identity Server abstract those details and differences away.

https://github.com/webmotions/fake-authentication-jwtbearer

[floyd-may]

JWTs are just buckets of claims with some optional signature validation. The advantage here is that if we teach FakeAuth how to speak JWT, it's more idiomatic and interoperable on the web. Looking at the webmotions stuff, it looks like they're doing... "interesting" things with the issuer, which I'd like to stay away from, honestly. Issuer is actually one of the easy ways to differentiate whose token it is when doing multi-auth (i.e. tokens could come from one of many IdPs).

Hope the new gig's going well! Holler at me sometime, I'd love to catch up.