Infer some authentication requirements from `securitySchemes` in OpenAPI spec

[erwinkramer]

The securitySchemes in OpenAPI spec defines some authentication requirements for APIs, such as API Keys and OAuth.

Would be nice if the tool understands this and allows you to add an API Key, or OAuth client credentials (or even starts an Authorization Code Flow for OAuth).

[HimethW]

Thank you for raising this issue. You're right that we don't currently read securitySchemes.
Inferring auth requirements from the OpenAPI spec is a good idea and not something the tool handles today.

In the meantime, there is a work-around where credentials can be passed as ordinary step parameters, which works on the current release:

- stepId: getUser
  operationId: getUserById
  parameters:
    - name: X-API-Key
      in: header
      value: $inputs.apiKey

Because in accepts header, query and cookie, this covers three apiKey scheme locations.
A bearer token is the same idea:

    - name: Authorization
      in: header
      value: "Bearer {$inputs.token}"

OAuth client credentials can also be expressed. Since a step's outputs feed later steps, the token exchange can be part of the workflow itself.

- stepId: getToken
  operationId: oauthToken
  requestBody:
    contentType: application/x-www-form-urlencoded
    payload:
      grant_type: client_credentials
      client_id: $inputs.clientId
      client_secret: $inputs.clientSecret
  outputs:
    accessToken: $response.body#/access_token

- stepId: callApi
  operationId: getUserById
  parameters:
    - name: Authorization
      in: header
      value: "Bearer {$steps.getToken.outputs.accessToken}"

We'll discuss making auth a dedicated capability of the tool, driven by securitySchemes for an upcoming release.
Thanks again for the feedback