Interfaces
OAuth
OAuth lets an application act on behalf of a user, with per-user scopes and consent — resolving to the same authorization model as every other DigitalStack interface.
Preview
API key or OAuth?
Use an API key
Available- • Internal scripts and controlled automation
- • Direct server-to-server integrations you operate
- • A single workspace identity you manage yourself
Use OAuth
Preview- • Third-party apps acting on behalf of a user
- • Connected AI clients (see MCP)
- • Delegated, revocable, per-user application grants
API keys are not deprecated — they remain the supported way to authenticate server-to-server requests to the REST API.
How delegated access works
Your app asks DigitalStack for access
The user reviews and approves the scopes
DigitalStack issues an access token
Your app calls the API as that user
Security model
- • Least privilege — an app requests only the scopes it needs
- • Explicit consent — the user approves access on a DigitalStack screen
- • Delegated identity — the app acts as the user, not as a shared secret
- • User permissions stay authoritative — an app can never exceed what the authorizing user can do
- • Revocable — access can be withdrawn without rotating a shared key
What's available today
Honest status for each OAuth capability. Only what's planned or unavailable is flagged below — everything else here is real and working, though still gated behind a per-deployment rollout flag (see each capability's note).
Delegated OAuth for AI clients (MCP)
Connected AI clients can act on a user’s behalf using OAuth access tokens that DigitalStack independently verifies as a resource server.
Enabled per deployment and validated with early partners — not yet generally available.
Consent & authorization screen
A DigitalStack-hosted consent screen lets a user review and approve what an application may access before access is granted.
Part of the delegated-OAuth flow, which is enabled per deployment.
Dynamic client registration
Supported clients can register dynamically through the backing identity provider, so no manual client setup is required.
Available for supported clients within the gated delegated-OAuth flow.
Delegated-identity revocation
A user can revoke DigitalStack's local trust of their delegated identity, cutting off every future request from it starting with the very next one.
This is DigitalStack revoking its own trust locally (P2 Slice 2), not an upstream Stytch token/session revocation — DigitalStack never calls Stytch to invalidate the token itself. That is sufficient because DigitalStack is the only resource server trusting a token scoped to its audience. It also revokes the whole delegated identity (shared by every Connected App using the same identity provider), not one specific app's grant — see the Connected Apps docs for that distinction. Part of the delegated-OAuth flow, enabled per deployment.
Token refresh
Getting a new access token for a long-lived connection without the user re-authorizing.
Not something DigitalStack does — DigitalStack never issues or holds the token, so refreshing it happens entirely between the client and Stytch, upstream and invisible to DigitalStack. There is no DS code path here at all, by design, not as a gap.
Authorization-server discovery for generic clients
Standardized discovery metadata so any MCP/OAuth client can auto-configure against DigitalStack.
Not advertised yet — generic-client setup varies. Use a client with first-class custom connectors today.
OAuth for the standard REST API
Delegated, per-user OAuth access to the REST API with application identity, granular scopes, consent, and revocation.
This is the same gated delegated-OAuth mechanism as MCP, not a separate feature — the shared route wrapper resolves an OAuth bearer token identically to an API key for any scope-gated route, including the standard REST v1 API. Enabled per deployment and validated with early partners — not yet generally available.
Server-to-server (client credentials)
A machine-to-machine OAuth grant for backend integrations with no user present.
Server-to-server integrations use API keys today. An OAuth client-credentials grant is not offered.
Rate limiting for OAuth-authenticated requests
OAuth-authenticated REST, GraphQL, and MCP requests are rate-limited identically to API keys — the same default budget, no extra headroom (P2 Slice 2).
OAuth for the REST API
PreviewDelegated OAuth already resolves against the standard REST API today, the same way it does for MCP — application identity, per-user scopes, consent, and revocation — gated behind the same per-deployment rollout. The REST API also supports API-key authentication, which remains the simplest path for most integrations.
This is the same gated delegated-OAuth mechanism as MCP, not a separate feature — the shared route wrapper resolves an OAuth bearer token identically to an API key for any scope-gated route, including the standard REST v1 API. Enabled per deployment and validated with early partners — not yet generally available.