Learn Secret Management - Authentication Methods (Token, AppRole, Userpass, OIDC)

#Introduction

In episode 7 you created policies that define access rights. But a policy without identity is just a rule on paper — you need something that proves "who" you are. Episode 8 discusses Authentication Methods: the mechanisms for users and machines to identify themselves to OpenBao and obtain a token that carries policies. Choose the right auth method, and the login flow takes care of itself.

#What is an Authentication Method

An authentication method is the entrance to OpenBao. Every auth method produces a token that carries identity and policies. The engine is enabled with bao auth enable and occupies the auth/<name> path.

Here is a quick comparison of common auth methods:

At its core, an auth method turns external credentials into an internal OpenBao token. Once you have a token, the rules that follow are determined by the policies from episode 7.

#Token Auth Method and Token Types

The token auth method always exists and cannot be disabled — even logging in through another auth method ultimately issues a token. OpenBao has four token types with different characteristics:

Service tokens can be lookup-ed, renew-ed, and revoke-d individually. Batch tokens are so lightweight they suit high load, but they carry no lease metadata and cannot be renewed. Periodic tokens are used for continuously running processes, while orphans protect a token from the side effects of revoking its parent token.

Example of creating various token types:

bao token create -policy=my-policy
bao token create -type=batch -policy=my-policy
bao token create -type=periodic -period=24h -policy=my-policy
bao token create -orphan -policy=my-policy

#Human Auth Methods: userpass

For humans, the simplest auth method is userpass — logging in with a username and password. Enable it, then create the user:

bao auth enable userpass
bao write auth/userpass/users/budi \
  password="sandiKuat123" \
  token_policies="my-policy"

bao auth enable userpass enables the engine at the auth/userpass path. After that, budi can log in with bao login -method=userpass username=budi and enter the password just created — and the resulting token carries the my-policy policy.

#SSO for Humans: OIDC and Similar

For larger team scale, manually authenticating users one by one is impractical. This is where SSO comes in. OpenBao supports OIDC natively, plus integrations with popular providers:

• OIDC — the modern OpenID Connect standard; pairs well with Authelia, Authentik, Keycloak, and similar providers.
• GitHub — developers simply log in with their personal GitHub token.
• Okta — company accounts already centralized in Okta.
• Azure AD — identities from Microsoft Entra ID.

The flow is similar for all providers: enable the engine, configure client_id, client_secret, and redirect_uri, then map identity claims to policies. After that, users log in through the browser and a token is issued automatically. A single SSO account can carry several policies at once — for example, mapping from an Okta group to a specific policy.

#Machine-to-Machine: AppRole

For applications and microservices, no human is involved — machines must log in. The approle auth method is the de-facto standard for this need, using two-part credentials:

• RoleID — a static identity similar to a username; often stored as a configuration file.
• SecretID — a dynamic credential similar to a password; created one by one and with its own TTL.

The setup steps:

bao auth enable approle
bao write auth/approle/role/my-app \
  token_policies="my-policy" \
  secret_id_ttl="1h" \
  token_ttl="1h"
bao read auth/approle/role/my-app/role-id
bao write -f auth/approle/role/my-app/secret-id

The application stores role_id and secret_id, then logs in:

bao write auth/approle/login \
  role_id="9c1f..." \
  secret_id="d4a8..."

The response is a token ready to use. Because SecretID has a TTL, a well-behaved application logs in again periodically — a concept we will return to in episodes 10 and 11. The AppRole advantage: no human passwords, easy rotation, and each application has its own identity that can be revoked without disturbing other applications.

#Conclusion

In this episode 8 you understood auth methods as the identity entrance: the token types from service to orphan, human authentication via userpass and OIDC SSO, and machine-to-machine authentication using AppRole with RoleID and SecretID.

Key takeaways:

• Tokens are identity, policies are rights — the two always go together.
• Choose the token type to match the load — batch for high load, periodic for long-running daemons.
• AppRole for machines, userpass or OIDC for humans — match it to whoever is logging in.
• SecretID must be short-lived — strict TTLs and routine rotation prevent misuse.

In the next episode, episode 9, we follow the trail of a dynamic secret after it is born: Lease Management — what a Lease ID and TTL are, how to renew them, and how to revoke access instantly when a leak happens.