Skip to content

Add Support for [RFC 6750] Bearer Token Usage (a.k.a. Opaque Tokens) #100

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

Closed
dfcoffin opened this issue Aug 21, 2020 · 4 comments
Closed
Assignees
Labels
status: duplicate A duplicate of another issue

Comments

@dfcoffin
Copy link

Expected Behavior

Current Behavior

Context

@dfcoffin dfcoffin added the type: enhancement A general enhancement label Aug 21, 2020
@jgrandja
Copy link
Collaborator

Closing as duplicate of #52

@jgrandja jgrandja self-assigned this Aug 21, 2020
@jgrandja jgrandja added status: duplicate A duplicate of another issue and removed type: enhancement A general enhancement labels Aug 21, 2020
@dfcoffin
Copy link
Author

#52 Implements RFC 7662 OAuth 2.0 Token Introspection.

This specification defines a method for a protected resource to query
an OAuth 2.0 authorization server to determine the active state of an
OAuth 2.0 token and to determine meta-information about this token.
OAuth 2.0 deployments can use this method to convey information about
the authorization context of the token from the authorization server
to the protected resource.

RFC 6750 The OAuth 2.0 Authorization Framework: Bearer Token Usage

This specification describes how to use bearer tokens in HTTP
requests to access OAuth 2.0 protected resources. Any party in
possession of a bearer token (a "bearer") can use it to get access to
the associated resources (without demonstrating possession of a
cryptographic key). To prevent misuse, bearer tokens need to be
protected from disclosure in storage and in transport.

Release 0.0.1 only supports JWT Tokens based on the release notes.

@jgrandja
Copy link
Collaborator

@dfcoffin The purpose of the Bearer Token Usage RFC 6750 is to specify how a client can use a bearer token when requesting a protected resource. The 3 options are header, form parameter and query parameter. The bearer token can be either opaque or self-contained (JWT). This spec is specific to the client.

The Token Introspection RFC 7662, specifies how a protected resource can introspect an opaque access token to determine the claims associated with the opaque access token in order to make an authorization decision. The authorization server will grant an opaque access token to the client and then the client will call the resource server, which in turn will call the authorization server's introspection endpoint to return the claims associated with the access token and apply the authorization. So the bottom line is that #52 will deliver opaque token support.

Hope all this makes sense?

@dfcoffin
Copy link
Author

Does Release 0.0.1 support the generation of JWT and Opaque Tokens? If not what currently listed tasks will produce an opaque access token?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status: duplicate A duplicate of another issue
Projects
None yet
Development

No branches or pull requests

2 participants