Expose securitySchemes key in auth callback

[matthewjamesadam]

Description

In our organization we have multiple securitySchemes to define different types of tokens required for different paths and services:

components:
  securitySchemes:
    bearerAuth:  { type: http, scheme: bearer }
    refreshAuth: { type: http, scheme: bearer }
paths:
  /data:
    get:
      operationId: getData
      security: [{ bearerAuth: [] }]
      responses: { '200': { description: ok } }
  /refresh:
    get:
      operationId: refresh
      security: [{ refreshAuth: [] }]
      responses: { '200': { description: ok } }

However in such a scheme, the auth callback can't distinguish between the security schemes relevant
to the call — Auth only carries the resolved scheme body, not the securitySchemes key:

auth: (auth) => {
  // auth === { type: 'http', scheme: 'bearer', name: 'Authorization' }
  // for both endpoints — no way to pick the right token.
}

So there is no way for a client to determine which token to provide.

Would you be open to me making a PR to resolve this? My proposal would be to add an optional key?: string to Auth carrying the securitySchemes key ('bearerAuth', 'refreshAuth').

I've looked at some related PRs (#231, #1768) but nothing seems to directly discuss this issue.

Thanks!

[pullfrog]

  ^{｜ Build this ➔ ｜ Make a plan ➔}

[mrlubos]

@matthewjamesadam would you be okay with defining the key only when there are duplicate schema signatures? I worry about exposing a redundant info for single/unique multi schemas because people already don't like the duplication it creates. Thoughts?

[matthewjamesadam]

@mrlubos do you mean that the proposed Auth.key property would only be provided if there are multiple security schemas defined with duplicate type/scheme properties, but otherwise would be undefined?

As long as the key property is provided on every API call in this scenario it would be fine, it definitely resolves the issue at hand. My only concern would be documenting and understanding a property which is provided in some contexts but not others -- someone using the Auth interface might be confused why there is a key property that is never populated.

[mrlubos]

@matthewjamesadam That's right. Well, the explanation would be it's provided only on conflict to allow deduplication. I'd be fine with always providing it later but we need to avoid duplicated definitions in the generated SDK and that's not currently the case

[matthewjamesadam]

Makes sense to me @mrlubos . I'll make a PR to implement this and let you look over it.

[mrlubos]

yep, let's unblock you and clean it up later!