# with one of them requiring the use of multiple schemes
security:
  - APIKey: []
    SigningKey: []
  - Bearer: []
```

Combining schemes like above give you the option to define AND/OR type functionality when it comes to the requirements of your API.

## How To Describe Security Schemes

[securitySchemes](https://spec.openapis.org/oas/v3.1.0#security-scheme-object/security-schemes) are the actual details of the options provided in the [security](https://spec.openapis.org/oas/v3.1.0#security-requirement-object) sections of your document. The security schemes are components that are defined with the [components](https://spec.openapis.org/oas/v3.1.0#components-object) section of your document. Below is an example of the 5 types of security schemes described above and how they are defined:

```yaml
---
components:
  schemas: ...
  responses: ...
  # The definition of the used security schemes
  securitySchemes:
    BasicAuth: # An arbitrary scheme name, we recommend something descriptive
      type: http
      scheme: basic
    Bearer:
      type: http
      scheme: bearer
      bearerFormat: JWT # Optional token format
    APIKey:
      type: apiKey
      in: header # or query/cookie
      name: X-API-Key
    OAuth:
      type: oauth2
      flows: # Many different flows are available - https://spec.openapis.org/oas/v3.1.0#oauth-flows-object
        implicit:
          authorizationUrl: https://test.com/oauth/authorize
          scopes:
            read: Grants read access
            write: Grants write access
    OpenIdConnect:
      type: openIdConnect
      openIdConnectUrl: https://test.com/.well-known/openid-configuration
```

## Best Practices

I generally recommend considering developer experience and weighing this up against the security requirements of your API. Consider its use cases such as will it be called from another server? A client? Or a combination of both. Based on your needs then try to describe your security requirements in your OpenAPI document as simply as possible, if you can avoid multiple options or too many per operation differences then it will generally require less friction for your end-user to get up and running and start using your API. This is the main reason we still see pre-shared secrets (described by the [apiKey](https://spec.openapis.org/oas/v3.1.0#api-key-sample) type above) being the most ubiquitous option amongst APIs today, but if not managed correctly it can be one of the least secure options available.