security: add support for Authorization header with Bearer authentication scheme

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

About authentication with JWT

Parent issue #585

+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.

@cbornet

@cbornet This issue is not just about JWT.

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

@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 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

@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.

https://2.bp.blogspot.com/-wlExmpcjcjw/WNKq_J7YeZI/AAAAAAAAC5g/ftwwzC1Rr0s3Jyz6AnehJCqvXC1zoWJPQCLcB/s1600/15.PNG

@ratanakpek

@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

@MikeRalphson with:

type: http
scheme: bearer
bearerFormat: JWT

I get: "User Warning: @OA\SecurityScheme() is missing key-field: "securityScheme""

@twitnic

@twitnic that sounds like a problem with a specific tool, not with the specification itself.

Navigation Menu

Repository navigation

security: add support for Authorization header with Bearer authentication scheme #583

16 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

security: add support for Authorization header with Bearer authentication scheme #583

Description

Activity

fehguy commented on Feb 29, 2016

dolmen commented on Feb 29, 2016

alecha commented on Feb 29, 2016

cabbonizio commented on Feb 29, 2016

dolmen commented on Mar 1, 2016

fehguy commented on Mar 1, 2016

ChrisPearce commented on Mar 3, 2016

jvivs commented on Mar 25, 2016

cbornet commented on Apr 12, 2016

K1ll3rF0x commented on Jun 27, 2016

dolmen commented on Jun 27, 2016

ponelat commented on Jun 27, 2016

dolmen commented on Jun 27, 2016

16 remaining items

cschachinger commented on Nov 30, 2016

vincentbarat commented on Dec 13, 2016

basharov commented on Dec 16, 2016

jtn-d commented on Dec 30, 2016

teemuniiranen commented on Jan 12, 2017

CollinGraves commented on Jan 20, 2017

fehguy commented on Jan 20, 2017

dsx1986 commented on Feb 17, 2017

fehguy commented on Feb 17, 2017

ratanakpek commented on Mar 23, 2017

ePaul commented on Mar 23, 2017

paulocdf commented on Jan 22, 2018

MikeRalphson commented on Jan 22, 2018

twitnic commented on Oct 17, 2018

MikeRalphson commented on Oct 17, 2018

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions