Skip to main content

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.

01Security requirements

An array of alternatives is not the same as one mandatory scheme.

Each object in an OpenAPI security array is an alternative. An empty requirement object can document authentication as optional even when another alternative lists OAuth or an API key.

security:
- {}
- OAuth: [read]
meaning: authentication can be optional
02Inheritance

Review the effective requirement at the operation.

Root-level security can apply broadly while an operation overrides it. Review the effective requirement after inheritance, and do not treat an unused component scheme as evidence of protection.

03Authentication ≠ authorization

Knowing the caller does not prove the caller may perform the action.

Authentication question

Is a recognized identity required for this operation?

Authorization question

Is that identity allowed to perform this function on this resource?

04Static 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 upstream gateway behavior.

Boundary

Use the contract to find ambiguity early. Then test the deployed identity and authorization path separately.