Skip to content

Improve support for bearer token authentication #4673

Closed
@leastprivilege

Description

@leastprivilege

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

Activity

self-assigned this
on Oct 22, 2017
Eilon

Eilon commented on Oct 26, 2017

@Eilon
Contributor

Moving to Backlog because this isn't in our current plans.

brockallen

brockallen commented on Oct 27, 2017

@brockallen

Your new virtual scheme system, I think, would address some of these.

Eilon

Eilon commented on Nov 1, 2017

@Eilon
Contributor

Ah, I've heard only a little bit about it. @HaoK / @Tratcher - thoughts?

HaoK

HaoK commented on Nov 1, 2017

@HaoK
Member

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

ycrumeyrolle commented on Nov 6, 2017

@ycrumeyrolle

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

leastprivilege commented on Nov 6, 2017

@leastprivilege
ContributorAuthor

Our handler is basically a decorator over the MS JWT and our introspection one. In lack of better options.

added this to the Backlog milestone on Dec 13, 2018
added
area-authIncludes: Authn, Authz, OAuth, OIDC, Bearer
Needs: DesignThis issue requires design work before implementating.
on Dec 13, 2018
Eilon

Eilon commented on Apr 3, 2019

@Eilon
Contributor

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.

ghost locked as resolved and limited conversation to collaborators on Dec 4, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Needs: DesignThis issue requires design work before implementating.area-authIncludes: Authn, Authz, OAuth, OIDC, Bearer

    Type

    No type

    Projects

    No projects

    Relationships

    None yet

      Development

      No branches or pull requests

        Participants

        @Eilon@brockallen@leastprivilege@Tratcher@ycrumeyrolle

        Issue actions

          Improve support for bearer token authentication · Issue #4673 · dotnet/aspnetcore