Protected endpoints require proof of access. Wget authenticates to a protected endpoint by sending an existing access token in the Authorization: Bearer header.
A bearer token is a reusable secret until expiry or revocation. Anyone who obtains it can exercise its permissions, so it needs the same care as other credentials. Wget sends a token that the service has already issued; sending the bearer header does not obtain or refresh an OAuth access token.
Reading a token from a restricted file does not protect it once the shell expands it into Wget's process arguments. A separate, restricted Wget configuration file keeps the token out of those arguments. The file still contains a readable secret, and its permissions cannot protect it from other processes running as your account or from an administrator.
The request URL must be the HTTPS endpoint authorized to receive the token, with api.example.net replaced by that host and path. Sending the token to another service gives that service the credential. The report.json output file is overwritten if it already exists.
Steps to send a bearer token with Wget:
- Create an owner-only temporary Wget configuration file.
$ WGET_AUTH="$(mktemp)"
The shell stores the generated filename in WGET_AUTH. mktemp creates the file readable and writable only by your account. This method uses GNU Wget 1.21.x or 1.25.0, including the versions packaged by Ubuntu 22.04, 24.04 and 26.04 and Debian 12 and 13. BusyBox wget and Wget2 are different programs.
- Open the temporary file in your text editor.
$ vi "$WGET_AUTH"
- Enter the bearer header containing your existing access token.
header = Authorization: Bearer YOUR_ACCESS_TOKEN
YOUR_ACCESS_TOKEN stands for the token text, without additional quotes or a second Bearer prefix. The token belongs in this restricted file, not in a shell command or your global ~/.wgetrc. Editor backups and recovery files can also retain it.
- Save the configuration with your editor's save-and-exit command.
- Send the bearer header to the intended HTTPS endpoint without following redirects.
$ wget --config="$WGET_AUTH" --max-redirect=0 --server-response --output-document=report.json https://api.example.net/v1/reports/daily.json ##### snipped ##### HTTP/1.1 200 OK Content-Type: application/json ##### snipped #####
The --config option reads the header from the named file for this invocation; it does not install it as a default for other requests. Passing --header="Authorization: Bearer $ACCESS_TOKEN" directly would put the expanded secret in process arguments. The --max-redirect=0 option refuses every HTTP redirect, including redirects on the same host. A 3xx response requires a separately reviewed destination rather than removing this restriction.
A 401 Unauthorized response can indicate an expired, revoked, malformed, or wrong-audience token. A 403 Forbidden response can indicate insufficient scope or other access policy. The WWW-Authenticate header and the service's error body can explain the rejection.
- Remove the temporary credential file when Wget finishes.
$ rm -- "$WGET_AUTH"
Removing the file does not revoke the token or securely erase disk blocks, editor backups, snapshots, or other copies. A token suspected of exposure needs revocation or rotation through its issuer.
- Check the downloaded response for the protected resource you requested.
$ cat report.json { "report_id": "daily-current", "status": "ready", "download_url": "https://api.example.net/v1/reports/daily-current.csv" }
The HTTP success status and expected resource content together confirm the request succeeded. A login page or unexpected body is not proof of authenticated access; the response content depends on the endpoint.