-
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
Scopes for jwt-based security scheme #1393
Comments
Possibly related: #1366 |
My one hesitation in reusing the This potential confusion could be addressed by having a |
Feedback on any potential confusion in reusing the term |
I was just thinking of something similar. |
Chiming in support here, 15 months later. We're using OpenAPI3 to define the API spec for an internal platform with its own internal user/password authentication that provides JWT access and refresh tokens. The access tokens define the scopes that the user can access, and I have no official way to call this out in our api spec. The scopes functionality really needs to not be artificially walled off from Bearer tokens or any other scheme where a JWT could be used. Edit: Realized after posting that this has been formalized in the 3.1.0 spec, which at the time of this writing is in RC1. Non-OAuth2/OIDC schemes can now use "roles" in the same way the aforementioned use scopes. They're not defined at the security scheme level as scopes are, but can be specified in the global-level or path-specific security block. |
Would it be possible for something like swagger-api/swagger-node#481 with it's use of "x-security-scopes" be standardised so that it could be reported through swagger-ui?
If the array in the Security Requirements could be populated with scopes for a new security definition of "jwt", that might be one way to do it.
Thanks,
The text was updated successfully, but these errors were encountered: