Bearer tokens let cURL send an issued access credential to an API without repeating a password or browser session on every request. This fits OAuth 2.0 access tokens, service-account calls, and repeatable CLI checks against protected endpoints.
In cURL, the dedicated option for this job is --oauth2-bearer. It formats the standard Authorization: Bearer header for the request and keeps the command shorter than building that header manually each time.
Bearer tokens remain reusable secrets until they expire or are revoked. Keep them out of shared shell history, verbose logs, and tickets, and be especially careful with --location or other redirect-following flows because the credential should only reach the host that is meant to receive it.
$ ACCESS_TOKEN='eyJ...sig-redacted'
Replace the masked value with the real issued token in actual use, and prefer an existing restricted secret source when the workflow already has one.
$ curl --silent --show-error \
--oauth2-bearer "$ACCESS_TOKEN" \
--write-out '\nHTTP %{http_code}\n' \
https://httpbin.org/bearer
{
"authenticated": true
}
HTTP 200
The same option works with a real protected endpoint; success is the authenticated response plus the API's documented success status.
$ curl --silent --show-error \
--oauth2-bearer "$ACCESS_TOKEN" \
https://httpbin.org/headers
{
"headers": {
"Authorization": "Bearer eyJ...sig-redacted"
}
}
The Authorization line proves that cURL sent the bearer token in the standard header format before the request reached the application.
$ curl --silent --show-error \
--write-out '\nHTTP %{http_code}\n' \
https://httpbin.org/bearer
HTTP 401
A clear 401 Unauthorized confirms that the endpoint is enforcing bearer authentication instead of succeeding for unrelated reasons.
$ unset ACCESS_TOKEN
The variable disappears only from the current shell, so any copied logs, saved config files, or recordings still need separate cleanup.