Allow 'in' and 'name' fields for oauth2 securityDefinition

[rbren]

I've had the wonderful pleasure of implementing OAuth 2.0 clients for over a dozen different APIs while creating an OpenAPI-driven integration platform. While most implementations are similar, everyone seems to have their own idea as to where the access_token should be in requests.

For instance:

• Google expects header Authorization: Bearer xxxx
• GitHub expects query param access_token=xxxx
• Slack expects query param token=xxxx

I suspect that token location is supposed to be implied by the flow field, but allowing in and name in the securityDefinition would be an easy way to make that explicit, and allow support for APIs that have quirky OAuth 2.0 implementations.

[darrelmiller]

The OAuth2 spec RFC 6749 refers to RFC 6570 as the standard approach for providing tokens. Although there is latitude for providing a variety of ways to send the tokens, it does say that a resource server MUST support sending the access token using the bearer scheme in an authorization header.

As you state, this how Google handle it. GitHub also supports the auth header approach and states a preference for it. I couldn't find information in Slack's documentation as to whether they also support it.

If a provider doesn't support using the Auth header, then it is possible to use the other security mechanisms to describe how it wants to the token to be sent. Personally, I'd rather not add a flexibility to the OAuth description that isn't necessary, as per the specification.

[rbren]

Makes sense. I think creating a standard that's in conflict with the OAuth spec would be in poor form - if that MUST was a SHOULD I might argue though :)