Identity resolution is how the SDK decides which grant backs aDocumentation Index
Fetch the complete documentation index at: https://docs.alterauth.com/llms.txt
Use this file to discover all available pages before exploring further.
vault.request() call.
Three modes. They appear in this order everywhere in these docs because that’s the order to consider them in:
- JWT — recommended for apps with an IDP and logged-in users
grant_id— for scripts, batch jobs, and managed secrets- Headless — for CLIs, notebooks, and agents bootstrapping their own grants
vault.request() method serves all three. Only the wiring differs.
1. JWT — recommended for user-driven flows
Configure an Identity Provider, pass auser_token_getter at construction, and the SDK resolves the user’s grant from their JWT on every call.
grant_id in its own database. Deprovisioning a user in the IDP automatically locks them out of grants they own.
Full setup →
2. grant_id — for scripts, batch jobs, and managed secrets
Pass an explicit grant_id per call. Use this when:
- The call has no end user (cron jobs, webhook handlers).
- A managed secret (developer-owned credential) is in use.
- Explicit control over which grant a request uses is needed.
3. Headless — for CLIs, notebooks, and agent bootstrap
vault.connect() and vault.authenticate() open a browser, walk through OAuth, and return a grant_id usable immediately. No frontend, no callback URL.
Picking one — the short version
See also
- Principals and grants — the concepts each mode produces a principal for
- OAuth → JWT identity — full JWT setup
- OAuth → grant_id identity — explicit
grant_idflows - OAuth → Headless —
connect()andauthenticate()