Applications

Descope provides applications to handle various identity federation scenarios. Understanding the different types of applications and their use cases is essential for implementing the right authentication strategy for your needs.

Choosing an App Type

The app type depends on what the token has to do, not on whether you built the application yourself. A Federated App signs a user in to an application. An Inbound App gets access tokens for APIs.

The deciding question is whether the application's token has to name a specific Resource and carry its scopes. Only Inbound Apps accept the resource parameter, so those applications must be Inbound Apps, even first-party ones.

If the application only needs to sign users in, it stays a Federated App.

The table covers applications that sign users in or receive tokens from Descope. If you need to store your users' tokens for a third-party service such as Google or Slack, use an Outbound App in a traditional application, or a Connection when you're building agents and MCP servers.

A single product often needs more than one type, and you decide per application. For example:

• Web app: A public Inbound App that uses PKCE and sends resource, because its token must carry its API's Resource and scopes.
• Backend: A confidential Inbound App that exchanges the user's token for a token to a second API. Only Inbound Apps and Agentic Clients can call token exchange.
• Other portals: Federated Apps, because they only sign users in.

A Federated App's token can still be the one the backend exchanges, as long as its audience and a Policy allow it. See Getting a Token for Your Own API.

Federated Apps

Federated Applications in Descope enable you to establish secure Single Sign-On (SSO) connections between your applications and Descope, which acts as the Identity Provider (IdP). This allows users to authenticate once with Descope and gain access to multiple connected applications without needing to log in separately to each one.

Key characteristics

• Single authentication point for multiple applications
• Centralized user management
• Seamless user experience across applications

When to use Federated Apps

Federated apps are essential when you want to:

• Manage federated login across multiple different applications and domains
• Provide seamless access across different applications
• Centralize user management and access control

For example, if your organization has multiple applications (like an internal portal, customer dashboard, and admin panel), you can configure them as federated apps. Once a user logs in to any of these applications through Descope, they'll have seamless access to all other connected applications.

Inbound Apps

Inbound Apps enable your application to act as an OAuth provider, allowing third-party applications to authenticate and access your resources securely. This lets you manage user consent, permissions, and API access while maintaining control over your authentication system.

Descope exposes standard OAuth routes under /oauth2/v1/apps/, including /authorize and /token. See Authorization server endpoints and the API reference.

Key characteristics

• Your application becomes the OAuth provider
• Fine-grained control over API permissions through OAuth scopes
• Centralized consent and permission management
• Support for both user-based and machine-to-machine (M2M) authentication

When to use Inbound Apps

Inbound apps are essential when you want to:

• Allow third-party applications to integrate with your platform securely
• Provide API access to external services while maintaining control over permissions
• Support automated workflows and AI agents that need secure access
• Build a marketplace or platform where partners can integrate their services
• Support M2M integrations with secure token-based authentication

Outbound Apps

Outbound Apps let you securely connect your users to third-party providers, without relying on those providers as primary authentication methods. Think of them as a token vault, or an extension of OAuth social login, where you can define default scopes, progressively request new scopes, and rely on Descope to automatically manage and refresh access tokens on your behalf.

Key characteristics

• Connect to third-party providers for additional permissions
• Manage OAuth tokens and refresh cycles automatically
• Control default scopes and request additional scopes if needed
• Works with MCP and AI-related tools for token management for external API connections

When to use Outbound Apps

Outbound apps are essential when you want to:

• Manage permissions for AI tools with external APIs
• Manage multiple OAuth tokens for users/tenants with the right scopes

Resources

Resources are OAuth resource servers you define in the Descope Console. There are two types: API Resources (scopes mapped to RBAC roles) and MCP Server Resources (MCP scopes mapped to Connection scopes when tools use external APIs). MCP Server Resources also appear under Agentic Identity Hub → MCP Servers.

Key characteristics

• Create API or MCP Server Resources from one console area
• API Resources: OAuth scopes ↔ Descope roles
• MCP Server Resources: OAuth scopes ↔ Connection scopes; same server in Agentic Identity Hub
• Resource servers validate Descope-issued JWTs (aud, scope, project JWKs)

When to use Resources

Define Resources when you want to:

• Register APIs or MCP endpoints as OAuth-protected servers
• Control API access with scopes and internal roles, or MCP tool access with Connection mapping
• Issue tokens that clients can use directly with servers that you use Descope to protect

Pair Resources with Inbound Apps (API OAuth clients) or Agentic clients (MCP), not Federated Apps. See Managing Resources. Resources differ from Outbound Apps (vaulted third-party credentials).