New Security Definitions Proposal

[kinlane]

I migrated Jeremy Whitlock's security proposal from the spec repo so we can workshop it here, and I wanted to capture a few of the comments on the original PR here while continuing the discussion.

[kinlane]

Jeremy: This purpose of this proposal is to rethink how Security Schemes are defined in OpenAPI. This proposal would separate the credential location(s) from the Security Scheme type and would allow for complete control over dictating where the credential(s) are provided for a Security Scheme. This proposal will add a generic way to retrieve a credential from anywhere in a request, and allow any Security Scheme to dictate where its supported credential(s) are instead of relying on OpenAPI-supported conventions/opinions. This proposal also separates the credential location(s) details from the other configurations associated with the Security Scheme (like JWKS details for JWT).

[kinlane]

Basically I feel this proposal is attempting to do several things (and gets caught up trying to be backwards compatible as well):

• allow (some) credentials in body and path
• allow JWTs with some type-specific config
• genericise credential locations and config

It's not clear to me why all these things are or need to be combined.

[kinlane]

MikeRalphson on May 24 - "Unfortunately, the types supported by OpenAPI ... often tie the credential location to the Security Scheme type". Can you expand on why this is "unfortunate"? Type apiKey can already be located in any of query, header,cookie, and arguably if you try to put your Bearer token anywhere other than in an Authorization header, you are not doing oAuth2.

whitlockjc on Jul 28 - The point was more about separating the credential location(s) from the Security Scheme type. API Key is the closest to allowing free-form credential locations while others do not. I can see where some Security Schemes where these are locked down, like OAuth 2.0 (while it uses Bearer Tokens, I don't think it supports them being in all locations a Bearer Token could be represented), but this separation is really a flexibility thing than just trying to support JWT.

whitlockjc on Jul 28 - It would also be nice to have a way to describe a type not supported by OAS, where our locked-down types don't fit and a customer wants to still describe their security needs.

[kinlane]

MikeRalphson on May 24 "OpenAPI being so opinionated about these kinds things does not serve any real benefit to anyone involved" - Unsure this is totally true. Tooling authors may appreciate the limited set of possibilities they have to support?

@whitlockjc whitlockjc on Jul 28 - It's subjective for sure but is focusing on the tooling authors more important than the consumers of OpenAPI? I think with a clean implementation, it shouldn't be too hard to support something like this as a fellow tooling author to another.

[kinlane]

MikeRalphson on May 24 - These multiple locations, are they AND or OR?

@whitlockjc whitlockjc on Jul 28 - I would suggest we do something like how the Security Requirements work now, which would allow for an AND or an OR. But in the case of having an AND of the same credential location, I can't think of a case where you'd say I want the same to credential to be supplied in multiple places at the same time.

[kinlane]

Jeremy: A few notes after presenting this to the Security SIG: I could see a case where the Credential Object might also allow for a credential property in place of a credentials property. I could see a case where OAS might have some pre-defined credential (or credential formats, like HTTP Auth) There may be a case where we might need to allow for more JWT claims described for the jwt Security Scheme (I know on the backend this could be useful but seeing as this isn't the intent, I am not sure there is a case for this but it came up in the meeting so we'll wait for examples.)

[whitlockjc]

I missed this somehow. 🤦‍♂️ Can we resurrect this conversation?