What Is a Bearer Token? Whoever Holds It Gets In
A bearer token is a credential where simply possessing it grants access, presented in the HTTP Authorization header so the server trusts whoever bears it.
The name says it all: whoever bears the token can use it. There is no extra proof of identity, so the token itself must be kept secret in transit and at rest. Pipelines attach bearer tokens to API calls constantly, which makes leak prevention and short lifetimes important.
Possession is access
A bearer token requires no additional credential. If you can present it, the server grants the access it represents, which is convenient but means a leaked token is immediately usable by anyone.
How it is presented
The token goes in the Authorization header as "Bearer <token>". The server validates it and authorizes the request based on what the token represents.
Why secrecy matters
- Only ever send bearer tokens over HTTPS.
- Never log them or print them in CI output.
- Prefer short lifetimes to limit leak damage.
Bearer tokens in CI/CD
Pipelines store tokens as masked secrets and attach them to deploy and API calls. CI platforms mask known secret values in logs, but a token printed by accident can still leak, so handling is careful.
Short-lived is safer
Minting a fresh, short-lived token per run, rather than reusing a long-lived one, limits the window an exposed token is useful. OIDC-based flows make this practical for CI.
Auth errors are not blips
A 401 from an expired or wrong bearer token fails the same way every run, so it is not retryable. Latchkey runners retry transient transport failures to common endpoints but surface genuine 401s so you refresh the token.
Key takeaways
- A bearer token grants access to whoever presents it, with no extra proof.
- It must travel only over HTTPS and never appear in logs.
- Short-lived tokens limit the damage if one leaks; a 401 is not retryable.