Closed
Description
The current JwtBearer middleware is pretty limited.
We need support for scenarios where an API can accept different token formats - e.g. JWT and reference token (both would use the bearer scheme on the authorization header).
What we need is
-
general purpose "bearer token authentication middleware"
- retrieves tokens from the rfc6750 specified locations
- all the necessary validation etc
- proper eventing model to retrieve tokens from other locations etc
-
extensible token validation infrastructure
- they probably need to come from DI because they need support for other dependencies like caching etc
- they need access to the "top level" options - e.g. the discovery document
Metadata
Metadata
Assignees
Labels
Type
Projects
Milestone
Relationships
Development
No branches or pull requests
Activity
Eilon commentedon Oct 26, 2017
Moving to Backlog because this isn't in our current plans.
brockallen commentedon Oct 27, 2017
Your new virtual scheme system, I think, would address some of these.
Eilon commentedon Nov 1, 2017
Ah, I've heard only a little bit about it. @HaoK / @Tratcher - thoughts?
HaoK commentedon Nov 1, 2017
I'm not exactly sure I understand the specifics of what's being asked for. But the general idea for the virtual scheme is the ability to reuse other scheme handlers easily.
So if they just wanted to authenticate using the exact JwtBearer logic, but do something different for challenge/forbid etc, the virtual schemes will be making that easier.
Basically virtual schemes won't give you any more extensibility for any existing auth handler's functionality, but you will be able to compose/reuse/mix and match them on a per action (Authenticate/Challenge/Forbid/SignIn/SignOut) way that wasn't really possible before.
ycrumeyrolle commentedon Nov 6, 2017
Agree with @leastprivilege for the support of reference token.
Maybe an abstract bearer authentication handler, with a JWT bearer handler and a reference token bearer handler.
We are using from the same way both token (JWT within a secure environment, reference token for hostile environment like the Internet). As we have to audit security events, a common layer of events would avoid out of synch behaviour.
We are currently dealing with https://github.com/IdentityServer/IdentityServer4.AccessTokenValidation
leastprivilege commentedon Nov 6, 2017
Our handler is basically a decorator over the MS JWT and our introspection one. In lack of better options.
Eilon commentedon Apr 3, 2019
Closing because there are not current plans to implement this and there doesn't seem to be significant demand for this in comparison to other features.