-
Notifications
You must be signed in to change notification settings - Fork 10.3k
Improve support for bearer token authentication #4673
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Moving to Backlog because this isn't in our current plans. |
Your new virtual scheme system, I think, would address some of these. |
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. |
Agree with @leastprivilege for the support of reference token. 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 |
Our handler is basically a decorator over the MS JWT and our introspection one. In lack of better options. |
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. |
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"
extensible token validation infrastructure
The text was updated successfully, but these errors were encountered: