OAuth Grant Types

When your app needs tokens from Descope, and you want to use Descope as a Federated Identity Provider (IdP) with OAuth 2.0/2.1, it does that through one of the standard OAuth 2.0 / OpenID Connect grant types.

The protocol is the same whether you are using an OIDC Federated App or an Inbound App.

With a Federated OIDC App, Descope is the identity provider your users sign into for your product. There is no third-party consent screen for Resource scopes, and you are not modeling API permissions as Resources on that path. With an Inbound App, Descope is the authorization server for clients that call your APIs or MCP servers: users or tenants consent to scopes on a Resource, those scopes (and mapped roles) show up in the token, and your API enforces them.

Both OIDC paths talk to familiar authorize and token endpoints. Federated OIDC lives under /oauth2/v1/...; Inbound Apps use /oauth2/v1/apps/.... For the full route lists, see OIDC Endpoints and the Inbound Authorization Server.

Diagrams

The interactive diagram below walks through each grant. Use the step controls to switch flows; the caption under each one calls out where Federated and Inbound Apps diverge.

1Authorization code2Authorization code + PKCE3Client credentials4JWT bearer5CIBA6Device authorization

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.

← Previous1 / 6Next →

When to use each grant

Not every grant fits every client. Use this table as a quick guide, then jump into the diagram above (or the runtime docs in Next steps) for the details.

There is one more grant worth knowing about after you already have a Descope token: token exchange (urn:ietf:params:oauth:grant-type:token-exchange). It lets you trade that token for one scoped to a specific Resource (or for an ID-JAG). You do not flip it on under Grant Types in the Console — what is allowed is controlled by Policies. See Token exchange for policy setup and the request shape.

Next steps

Once you know which grant you need, these pages cover configuration and runtime examples:

• To turn grants on for an Inbound App and set Manage options, see Creating Inbound Apps → Grant Types.
• For request and response examples, see Using Inbound Apps (Inbound) and OIDC Endpoints (Federated).
• For CIBA approval flows in the Flow builder, see Consent Flows.
• For how scopes and roles land in Resource-scoped tokens, see Scopes and Roles.