| Field | Description |
|---|---|
| client_token | Vault token to include in subsequent calls |
| accessor | Token accessor for lookup and revoke |
| policies | List of policies attached to the token |
| lease_duration | Time-to-live (TTL) for the token |
client_token, and include it in the X-Vault-Token header for all future requests.
You’re not storing tokens on disk as the CLI does. Securely manage your tokens in environment variables or secret managers.
Authenticating with AppRole
AppRole authentication allows machines or applications to authenticate to Vault. No existing token is required to perform this login.Prepare the Login Payload
Create a JSON file (auth.json) containing your AppRole credentials:
Send the Login Request
@auth.json: Path to the JSON payload withrole_idandsecret_id.- Endpoint:
/v1/auth/approle/loginsignals Vault to authenticate via AppRole.
Sample Response
A successful AppRole login returns a JSON object similar to:auth.client_token value—this is your Vault API token.
Using the Vault Token for Subsequent Requests
Include the token in theX-Vault-Token header for all Vault API calls. For example, to read a secret at secret/data/my-secret:
my-secret with the path to your desired secret. All reads, writes, renewals, and revocations follow the same pattern.
Avoid exposing your Vault token in shared logs or command-history. Use environment variables or CI/CD secret storage to keep tokens confidential.