-
Notifications
You must be signed in to change notification settings - Fork 9.1k
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
JWT-grant as a new Oauth2 flow #1875
Comments
#1393 seems kinda related, but I think it should be possible to distinguish between using custom/proprietary JWTs compared to the standard-based approach above. |
Hey @joergenb thanks for raising this issue. As you can see we have been wrestling with how to deal with the notion of scopes outside of the OAuth2 flow and how they related to JWTs. Whoa, I had never run into RFC7251 before and now my head hurts. Based on my intial understanding of what this is doing is it defines an extension mechanism to OAuth2 so that existing identity providers can invent their own grant_types and use those grant_types when making a token request. (Asusming the identity providers go off and write an extension based on 7251) To date when talking about OAuth2 flows, that generally defines which grant_type is used when making the token request. RFC7251 basically ignores the notion of flows and says give me a grant_type and the corresponding assertion. Having said that, this section https://tools.ietf.org/html/rfc7523#section-2.2 confuses me as it is using authorization_code as the grant_type. I agree we need to add support for these additional grant_types. I just need to get a better grasp of how this all fits together to understand how it best fits into OAS. /cc @MikeRalphson |
In addition to JWT grant type, please also add SAML grant type. And if possible, allow us to extend the definition, like x-jwt-grant, x-saml-grant, x-wicked-grant, for example. |
I don't understand your point. RFC 7251 is a framework defining how to use assertions as authorization grants (in addition to other grants like authorization code or client credentials as defined in RFC 6749). Additionally, these assertions can be used to authenticate a client (see below). RFC 7523 defines JWT to be one specific kind of such an assertion.
The example you cited is about using JWT to authenticate the client, not using it as a grant at the token endpoint. So this is an alternative to using Basic Auth or adding
Proposal: components:
securitySchemes:
OAuthJB:
type: oauth2
flows:
jwtBearer:
tokenUrl: https://authorization-server.example.com/token
scopes:
read: Read a resource
OAuthSB:
type: oauth2
flows:
saml2Bearer:
tokenUrl: https://authorization-server.example.com/token
scopes:
read: Read a resource |
Any news on that? |
@darrelmiller like @johakoch wrote, using JWTs for Client Authentication can already be expressed as such, Currently all those information are usually in
To support instead JWT as Authorization Grant, it is probably required to register new keywords. |
Hi |
@SwapnilKhante No, I guess, it's not possible at the moment. Keep in mind that there is a difference between using jwt-bearer as grant ( |
Using jwt-bearer as a client authentication mechanism would be an alternative to specifying (client_id and) client_secret in the Swagger UI. However, if you want to support this alternative, there should probably be a way to specify client authentication alternatives per OpenAPI. In https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderMetadata there are e.g. |
RFC7523 extends Oauth2 by using JWTs as grants.
It would be nice if this behaviour could be added as a new type of flow under the Oauth2 securityScheme, in addition to existing ones (authorizationCode, implicit, etc.)
The full name in the RFC is
urn:ietf:params:oauth:grant-type:jwt-bearer
, but I guessJWT
will suffice. Apart from that, thetokenUrl
andscopes
would be needed.The text was updated successfully, but these errors were encountered: