Multiple Security Schems and Auth function

[programm-ingovals]

So I am consuming an API which has multiple Security Schemas.

  "securitySchemes": {
      "Bearer": {
        "type": "oauth2",
        "flows": {
          "authorizationCode": {
            "authorizationUrl": "...",
            "tokenUrl": "...",
            "scopes": {
              "profile": "Read Data"
            },
            "x-usePkce": "SHA-256"
          }
        }
      },
      "ApiKey": {
        "type": "apiKey",
        "name": "X-Api-Key",
        "in": "header"
      },
      ...

and the some endpoints support more than one with the SDK f.e. having this defined in one of these endpoints.

  security: [
            {
                scheme: 'bearer',
                type: 'http'
            },
            {
                name: 'X-Api-Key',
                type: 'apiKey'
            }
        ],

I'm thinking possibly that one issue here is that the auth function doesn't support Apikey, but not sure.

But lets say it was supported how would we use the auth function.

Currently the auth object pushed through contains { scheme: 'bearer', type: 'http' }

How would Hey Api determine between two or more schemas here?

[dosubot[bot]]

Hi @programm-ingovals! I'm Dosu and I’m helping the openapi-ts team.

Hey API uses a single auth function for authentication, which receives an argument indicating the auth scheme and should return the appropriate token for that scheme. This replaces the older approach of separate accessToken and apiKey functions. If your API requires multiple schemes (like Bearer and ApiKey), your auth function should inspect the argument and return the correct token for each scheme as needed. However, the documentation does not provide explicit examples for endpoints requiring both schemes at once, nor does it clarify how the SDK combines them if both are required by an endpoint. You may need to handle more complex scenarios using request interceptors to manually set multiple headers if the SDK doesn't do this automatically. More details on the auth function are available in the migration guide.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}   

[programm-ingovals]

@dosu In this case the endpoint requires either schema, not both.

if the SDK defines the endpoints security property as :

        security: [
            {
                scheme: 'bearer',
                type: 'http'
            },
            {
                name: 'X-Api-Key',
                type: 'apiKey'
            }
        ],

How does hey api determine which scheme to initiate the auth call with?

[dosubot[bot]]

Hey API's documentation doesn't specify how the SDK chooses between multiple security schemes when an endpoint allows either one (logical OR in OpenAPI). There's no documented way to control or configure which scheme is selected, nor is there an example of the auth function handling this scenario. The SDK appears to use a single auth function, and the selection logic—if any—is not described. If you need to control which scheme is used, you may need to handle it manually, for example by customizing the auth function or using request interceptors to set the appropriate headers yourself. More details on auth setup are here: https://heyapi.dev/openapi-ts/clients/axios.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}   

[mrlubos]

@dosu pretty good answers! @programm-ingovals the intent would be to use the first resolved value, although I vaguely remember someone altered the functionality to loop through all entries. Let me know if you have any thoughts on this feature or were you just curious?

[dosubot[bot]]

Thanks for clarifying! Based on the current intent, the SDK will use the first resolved security scheme when multiple are listed for an endpoint, though there may have been changes to try all entries. If you have any preferences or ideas about how this should work—like wanting to control which scheme is picked or supporting more explicit selection—feel free to share your thoughts!

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}   

[programm-ingovals]

Yeah, I have a project againt an API that offers both bearer and apikey access, but the current project I am using uses an APIKey but since bearer is first I only get bearer from Auth.

I guess I will use an interceptor for now but perhaps, instead of just accepting the first the function should list all and the answer should indicate which schema your token goes with. Maybe sending the schema object along with the accesstoken back f.e.