How Security Requirements are Implemented in OpenAPI

OpenAPI currently provides support for five different security schemes through the Security Scheme Object, including the following:

API Key (apiKey): API keys are a popular means for providing a coarse-grained security credential to API consumers. The popularity of API keys has waned somewhat, largely due to the fact they are not protocol-bound and therefore not standardized, and because they provide limited proofs-of-possession. However, they continue to be provided in OpenAPI.

HTTP (http): HTTP provides a pointer to any valid security scheme in the IANA Authentication Scheme registry. While there are several entries in this registry, probably the most popular are Basic Authentication - essentially a username and password - and Bearer Tokens in the context of OAuth 2.0.

Mutual TLS (mutualTLS): Mutual TLS is a security mechanism that is popular in financial service APIs as it enforces the verification of x509 certificates at both the client and the server. OpenAPI provides limited built-in metadata for this Security Scheme, and API providers must provide additional details to describe specifics like accepted certificate authorities and supported ciphers.

OAuth 2.0 (oauth2): OAuth 2.0 is a fundamental building block of the API Economy as it facilitates allowing users (real human beings) to delegate their access to a third party at a given service provider. It is therefore well represented in OpenAPI, with the means to describe the most important OAuth flows.

OpenID Connect (openIdConnect): Support for OpenID Connect is supported in providing a link to the OpenID Connect Discovery metadata. While this in itself does not provide much in the way of rich metadata, it provides a pointer to a very rich document that can be programmatically parsed, allowing API consumers to access and act on this information in their applications in an automated manner.