API Authentication
Documented authentication is only useful when its semantics are understood.
OpenAPI can describe security schemes and Security Requirement Objects, but a casual reading can miss optional authentication, operation-level overrides, or requirements that do not match the sensitivity of an operation.
Security requirements
An array of alternatives is not the same as one mandatory scheme.
Each object in an OpenAPI security array is an alternative. If one alternative is an empty object, the operation can be documented as accessible without authentication even if another alternative lists OAuth or an API key.
Inheritance
Review the effective requirement at the operation.
Root-level security can apply broadly, while an operation can override it. A security review therefore needs the effective requirement after inheritance, not a simple search for a scheme name somewhere in the document.
Also distinguish a declared scheme from a scheme actually used by the operation. Unused component definitions should not create false confidence.
Authentication ≠ authorization
Knowing the caller does not prove the caller may perform the action.
Bearer, API key, OAuth2, OpenID Connect, and other mechanisms can establish or carry identity. The server still needs to enforce whether that identity can execute a privileged function or access a particular object.
Authentication question
Is a recognized identity required for this operation?
Authorization question
Is that identity allowed to perform this function on this resource?
Static boundary
The contract describes intent; runtime proves enforcement.
OpenAPI does not prove token validation, issuer/audience checks, session behavior, policy-engine decisions, resource ownership enforcement, or whether an upstream gateway changes the effective policy.
Scan the declared security contract → · OpenAPI security checklist → · API security pillar →