This is the recommended primary path for any app with logged-in users. Configure an Identity Provider, pass 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.
user_token_getter at SDK construction, and stop tracking grant_id in the application database.
Why this is the default
| Without JWT identity | With JWT identity |
|---|---|
Store grant_id per user in the application DB | Backend resolves grant from JWT sub claim |
| Keep that mapping in sync as users add/remove connections | Auth source is the IDP — Alter follows it |
| Manually deprovision when a user leaves | Deprovisioning the IDP user revokes their grants |
Prerequisites
- An app in the developer portal.
- An IDP configured for that app — see OAuth → Identity Providers → Overview and the per-IDP guides (Auth0, Clerk, Okta, Keycloak, WorkOS, Custom OIDC).
- The user has completed OAuth at least once for the target provider.
The pattern
Construct the SDK once. Pass auser_token_getter that returns the current request’s JWT. Call vault.request(...) with provider="..." instead of grant_id=....
Wiring user_token_getter
user_token_getter is called on every request. It should return the JWT for the currently active end user. Two common patterns:
FastAPI (Python)
The Python SDK ships a FastAPI helper that pulls theAuthorization: Bearer … header into a ContextVar:
Express / generic Node
Stash the JWT inAsyncLocalStorage per request, return it from the getter:
Provider disambiguation
provider="google" resolves the user’s grant for Google. When a user has multiple accounts on the same provider (work Gmail + personal Gmail), pass account= to disambiguate:
account is omitted and exactly one grant exists, it resolves. When multiple grants exist and no disambiguator is provided, the SDK raises AmbiguousGrantError — see SDK → Errors.
What happens on the wire
- SDK calls
user_token_getter(), attaches the JWT to the outgoing call. - Backend verifies the JWT signature against the configured IDP’s JWKS.
- Backend extracts the
subclaim, looks up grants(app, user, provider). - When exactly one grant matches, the backend retrieves and refreshes the token, injects it into the upstream call.
- The provider response is returned to application code unchanged.
Verifying a JWT directly
Sometimes a JWT must be verified in application code without making a provider call (e.g., in middleware that runs before anyvault.request()):
sub claim or null. Uses the same JWKS verification path the backend uses on every request.
When not to use this
- Cron jobs / webhook handlers with no end user → grant_id identity.
- CLIs / notebooks / agent bootstrap → Headless.
- Per-call user override (rare): pass
user_token=jwtdirectly tovault.request().
See also
- Concepts → Principals and grants
- OAuth → Identity Providers
- SDK → Connect —
verify_user_token()reference - SDK → Errors —
AmbiguousGrantError,NoDelegatedGrantError,ScopeReauthRequiredError