security: add support for Authorization header with Bearer authentication scheme
dolmen opened this issue · 43 comments
In Swagger 2.0 there is no way to tell that the apiKey can be given in the Authorization header using a given (non-Basic) authentication scheme. For example the Bearer scheme defined in RFC 6750 that is used for OAuth2 but could be used also for non-OAuth2 authentication.
Proposal: add the API Key location authorization in the Security Scheme Object:
{
"type": "apiKey",
"in": "authorization-header",
"authenticationScheme": "Bearer"
}are you saying that the apiKey scheme described here:
https://github.com/OAI/OpenAPI-Specification/blob/master/versions/2.0.md#security-scheme-object
is insufficient?
Yes, of course, the security scheme of Swagger 2.0 is insufficient.
The apiKey scheme with in set to header is designed for a custom header where the api key will be the whole value of the header. For example:
{
"type": "apiKey",
"in": "header",
"name": "Authorization"
}
will send this:
Authorization: <apiKey>
I need this:
Authorization: Bearer <apiKey>
+1, I'm using JWT and I'd need the same thing
+1 in addition to using JWT
+1
+1
+1 for JWT support. But I would prefer something like "type": "jwt" as this gives more info about the type of authentication.
Here is a related approach to add JWT support into Swagger UI project swagger-api/swagger-ui#2234.
Does it make sense to put in a template?
Pro: covers a wide range of possibilities
Con: We lose the descriptive value, ie: We don't know what type of authentication (JWT, oAuth, etc) this is, we just know how the tools should implement it.
Template eg:
type: apiKey,
in: header,
name: Authorization
template: "Bearer {apiKey}"Conversely, we could just have...
type: bearer
# in header, implied
# name Authorization, implied
# Con: a little terse@ponelat wrote:
Does it make sense to put in a template?
Swagger implementations have already too many security holes that allow code injection. No need to add one more vector with templated content.
+1 for bearer token authorization support
+1 for bearer token authorization support
+1 for bearer token authorization support
Just a note, you don't have to write just a +1 comment, you can add your vote to other people's comments using the reaction button (" +
Kinda wish github added proper voting mechanism instead of the reaction button.
Any update on this feature ? Any way to use "Bearer TOKEN" in the Authorization header ?
It is on our backlog. We haven't forgotten. It just hasn't bubbled to the top of the list yet.
/me turns the heat to "high", hoping it bubbles more ;)
Thanks for the quick response
@jmls :-) Unfortunately, no matter how fast we get it into the 3.0 spec, there is still the "tooling needs to start supporting 3.0" delay.
Oddly enough, it looks like if I define oauth2 as the security, the language generator I'm wanting to use (typescript-nodejs) seems to generate the code I need ...
export class OAuth implements Authentication {
public accessToken: string;
applyToRequest(requestOptions: request.Options): void {
requestOptions.headers["Authorization"] = "Bearer " + this.accessToken;
}
}
then within each "api" I have
protected authentications = {
'default': <Authentication>new VoidAuth(),
'my_auth': new OAuth(),
}
and for each endpoint
this.authentications.my_auth.applyToRequest(requestOptions);
this.authentications.default.applyToRequest(requestOptions);
[snip]
return new Promise<{ response: http.ClientResponse; body: any; }>((resolve, reject) => {
request(requestOptions, (error, response, body) => {
I haven't gotten round to testing just yet, but the generated code seems to solve my issues ;)
I have attempted to address the missing support for bearer/JWT in this PR #807 Feedback encouraged. I'm not a fan of the bearerFormat field but as there is no standard for communicating this to clients, I'm not sure what the best approach is.
+1 for Bearer
+1 for Bearer support
+1 for Bearer support
+1 for Bearer
As a temporary solution that seems to work, at least to me, is to add "Bearer " prefix manually in the auth dialog of Swagger UI.
+1 for Bearer
+1 for JWT Bearer token
Need. JWT. Please.
@CollinGraves it will be supported in 3.0 through #818
+1 for JWT Bearer
Already added, no need to +1 here :)
I got error, I try to install the swagger but it error about $urltoDoc,.... in views/vendor/l5-swagger.index.blade.php. Please kindly help! Thanks!
Message error: below is the error msg.
@ratanakpek please note that this repository is about the OpenAPI specification, not any specific implementation. This issue specifically is about the next version of OpenAPI, for which there are no implementations yet.
It looks like you have a problem with some tooling (not sure which one) – please open an issue there (first have a look whether there already is an issue for this.) You'll need to provide more information, though.
Is it possible now to have the apikey using the Bearer authentication?
Authorization: Bearer <apiKey>
Yes, in v3.0 - see this example. You can omit the bearerFormat hint if you want.
Note that apiKey and http are different types of securityScheme.
@MikeRalphson with:
type: http
scheme: bearer
bearerFormat: JWT
I get: "User Warning: @OA\SecurityScheme() is missing key-field: "securityScheme""
@twitnic that sounds like a problem with a specific tool, not with the specification itself.