generated: '2026-08-27' method: searched source: https://openbao.org/docs/api/ ; https://openbao.org/docs/auth/ ; https://openbao.org/docs/concepts/tokens/ docs: https://openbao.org/docs/api/ name: OpenBao authentication summary: >- OpenBao is token-authenticated. Once an instance is unsealed, almost every operation requires a client token. The token is sent either in the X-Vault-Token request header or as an Authorization header using the Bearer scheme. There is no OAuth 2.0 authorization-code flow for the OpenBao API itself and therefore no scope surface - authorization is expressed as ACL policies attached to the token, not as OAuth scopes. Tokens are obtained from an auth method: each auth method exposes one or more UNAUTHENTICATED login endpoints, which are the only routes reachable with no credential at all (alongside sys/health, sys/seal-status and the unseal/generate-root attempt endpoints). schemes: - id: vault-token-header type: apiKey in: header name: X-Vault-Token description: The canonical way to present a client token. Used by the OpenBao CLI, UI and Go client. primary: true - id: bearer-token type: http scheme: bearer description: Equivalent alternative - Authorization Bearer . Accepted anywhere X-Vault-Token is. - id: mutual-tls type: mutualTLS description: >- The cert auth method authenticates a caller by TLS client certificate at POST /v1/auth/cert/login, exchanging the certificate for a client token. mTLS is an auth METHOD here, not a transport-level alternative to the token - the resulting token still authorizes subsequent calls. - id: openid-connect type: openIdConnect description: >- The jwt auth method accepts both raw JWTs and a full OIDC login flow. Separately, OpenBao can ACT AS an OIDC provider for third parties via the identity/oidc endpoints, serving its own .well-known/openid-configuration and JWKS from the running instance. auth_methods: - id: token path: auth/token note: Built-in. Tokens created directly, with TTLs, renewal, orphaning and use-limits. - id: approle path: auth/approle note: RoleID + SecretID, intended for machines and CI. - id: cert path: auth/cert note: TLS client certificates. - id: jwt path: auth/jwt note: JWT and OIDC. Supports CEL-based roles. - id: kerberos path: auth/kerberos - id: kubernetes path: auth/kubernetes note: Service-account token review against the cluster API. - id: ldap path: auth/ldap - id: radius path: auth/radius - id: userpass path: auth/userpass authorization_model: style: acl-policies description: >- Capabilities (create, read, update, patch, delete, list, sudo, deny) are granted per path glob by an ACL policy written in HCL or JSON and managed at sys/policies/acl/:name. Policies attach to tokens and to identity entities/groups. There are no OAuth scopes; sys/capabilities-self reports what the calling token may do on a path. sudo_paths: Some root-protected paths additionally require the sudo capability; the generated OpenAPI marks them with x-vault-sudo. namespaces: Requests are scoped to a namespace by the X-Vault-Namespace header or an equivalent full path. mfa: supported: true note: Login MFA (TOTP, Duo, Okta, PingID) is configured under identity/mfa and enforced by login-enforcement objects. response_wrapping: supported: true header: X-Vault-Wrap-TTL note: >- Any response can be wrapped into a single-use token by sending X-Vault-Wrap-TTL. The caller receives wrap_info instead of the payload and must unwrap at sys/wrapping/unwrap. This is OpenBao's secure-introduction primitive and is unusual enough to be worth naming explicitly. unauthenticated_endpoints: - /v1/sys/health - /v1/sys/seal-status - /v1/auth/:method/login/... (per auth method) - /v1/sys/unseal - /v1/sys/generate-root/attempt - /v1/sys/generate-root/update notes: - The X-Vault-* header prefix is retained deliberately for API compatibility with HashiCorp Vault, which OpenBao was forked from. - The X-Vault-Request header must be present on requests routed through an OpenBao Proxy configured with require_request_header; the CLI and Go SDK always set it.