Grant Types
Every Inbound App obtains tokens from Descope's shared token endpoint by sending a grant_type and the parameters that grant requires.
The grants below are authentication grants: they control how a client obtains its first token. Enable them under Grant Types when you create the Inbound App. The same toggles apply to Agentic Clients.
After a client holds a token, it may call the same endpoint with token exchange (RFC 8693) to retarget that credential to a specific Resource or Connection. Token exchange is not toggled per app — it is always available at the project level and gated only by Policies.
Interactive login where the user authenticates in a browser, then the client exchanges a short-lived code for tokens.
- Redirect to
/authorize, then exchange the code at/token. - With Inbound Apps, the user also grants consent to scopes on a Resource.
- With Federated OIDC Apps, Descope is the IdP for your app.
Authentication grants (per-app toggles)
| Grant | grant_type value | User involved? | Configured per app? |
|---|---|---|---|
| Authorization code | authorization_code | Yes — login + consent | Yes (default for most apps) |
| Refresh token | refresh_token | No — follows an earlier user grant | Issued with authorization code / CIBA |
| Client credentials | client_credentials | No — M2M / autonomous | Yes (confidential clients) |
| JWT bearer | urn:ietf:params:oauth:grant-type:jwt-bearer | Optional — external JWT may represent a user | Yes (confidential clients) |
| CIBA | CIBA backchannel + poll | Yes — out-of-band approval | Yes (confidential clients) |
After you have a token
| Capability | grant_type value | User involved? | Configured per app? |
|---|---|---|---|
| Token exchange | urn:ietf:params:oauth:grant-type:token-exchange | Depends on subject token | No — Policy only |
Device authorization
Device authorization (device_code) is documented for Federated OIDC Apps, not Inbound Apps. Inbound Apps use CIBA for similar headless approval scenarios.
Policies and Resources
Grant type decides how a client authenticates. Policies and Resources decide what it receives:
- Register each API or MCP server as a Resource with OAuth scopes.
- Add a Policy whose subject is the Inbound App and whose target is the Resource and allowed scopes.
- For user-delegated grants (authorization code, CIBA), consent can only approve scopes a policy already permits.
Token exchange is governed entirely by policy: the client trades a subject token it already holds for a new token scoped to a downstream Resource or Connection. See the dedicated page for setup and examples.
Choosing a grant
| Scenario | Grant |
|---|---|
| Partner app or AI agent acting for a signed-in user | Authorization code |
| Headless client — user approves on another device | CIBA |
| Backend service or autonomous agent with no user | Client credentials |
| Partner IdP already issued a JWT you trust | JWT bearer |
| Client already has a Descope token and needs one for a specific Resource or Connection | Token exchange |
| Extend a user session without re-consent | Refresh token |
Related
- Using Inbound Apps — request examples for each flow
- Authorization server endpoints —
/authorize,/token, and RFC details - Creating Inbound Apps — Console toggles and per-grant settings