Use Cases for Inbound Apps with Descope
Inbound apps in Descope enable third-party applications, services, and automated systems to securely access APIs and perform actions on behalf of users or organizations. By leveraging OAuth, inbound apps can authenticate using client credentials flow, enforce fine-grained authorization through scopes and roles, and integrate with external systems that require centralized authentication and access control.
This document outlines key use cases for inbound apps:
Managing Multi-Tenant Authentication for SaaS Applications
Overview
For multi-tenant SaaS applications, inbound apps provide tenant-specific authentication and authorization, ensuring:
- Each tenant has its own identity and access control policies
- Tenant-specific OAuth settings are applied dynamically
- Applications can enforce different roles and scopes per tenant
Example Use Case
A SaaS CRM application needs to:
- Allow companies to integrate their own identity providers
- Ensure users from different tenants cannot access each other's data
- Dynamically assign scopes based on tenant policies
Using inbound apps:
- Each tenant's identity provider is registered as an inbound app
- Tenant-specific OAuth policies are enforced via scopes
- Access tokens include the tenant ID, ensuring strict data isolation
OAuth Provider Implementation Patterns
Building an OAuth Provider for Marketplaces: The GitHub Model
Overview
Marketplaces need to integrate with multiple third-party applications while maintaining secure authentication. GitHub Marketplace exemplifies this pattern, where external applications request access to user repositories through OAuth.
How It Works
- Applications register as OAuth clients, defining required scopes
- Users authorize access through consent screens
- OAuth tokens are issued with specific permissions
- The marketplace enforces scope restrictions on all API calls
Example: Developer Tools Marketplace
A developer tools marketplace uses Descope as its OAuth provider:
- Third-party tools register as inbound apps
- Users grant permission through standardized consent flows
- The marketplace enforces uniform security controls across all integrations
- Users manage app permissions through a centralized dashboard
Implementing MCP Server Authorization
Inbound apps can be used to implement MCP server authorization, and protect MCP servers from unauthenticated access. To learn more about how to implement MCP server authorization, see the MCP page.
Machine-to-Machine Authentication
Overview
A critical use case for inbound apps is providing secure authentication for non-interactive systems like partner services, AI agents, and automation tools.
Implementation with Client Credentials Flow
Learn more about client credentials flow in the OAuth 2.0 specification.
Unlike user-centric authentication, machine-to-machine scenarios rely on the OAuth client credentials flow:
Example: Logistics API
A logistics company secures its shipment tracking API:
- Partner systems authenticate using client credentials
- Each partner receives scopes limited to their shipments
- AI agents use the same protocol to fetch data for predictions
- All access is logged and can be audited centrally
Authenticating CLI Applications with PKCE
Overview
Inbound apps can also be used to authenticate users from a command-line interface (CLI). In this case, the CLI acts as a public client and typically uses the OAuth 2.0 authentication code flow (w/ PKCE).
A CLI tool starts the PKCE flow, opens a browser window for the user to log in, and exchanges the authorization code for an access token and refresh token. The CLI stores the tokens locally and uses the access token when calling backend APIs.
Example Use Case
A developer is building a CLI tool for their service and needs to:
- Allow end-users to log in using the same Descope flows as the web app.
- Store an access token and refresh token locally for API calls.
- Refresh tokens without requiring a client secret.
Using Inbound Apps:
- Create a new inbound app with non-confidential client.
- The CLI initiates the PKCE flow and obtains tokens without a client secret.
- The CLI refreshes tokens successfully, again without a client secret, as expected by the OAuth 2.0 specification for public clients.
- When using inbound apps, the client must request the appropriate set of scopes. If your resource server does not rely on scopes, the CLI can simply request the
openid
scope.
By default, inbound apps created in the Descope Console are confidential clients, which means a client secret must be supplied when refreshing tokens. This does not work for CLI applications that do not have a client secret.
Conclusion
Inbound apps in Descope provide a flexible, secure way to authenticate third-party applications, AI agents, and machine-to-machine systems across multiple scenarios:
- User-delegated access for marketplace integrations
- Service-to-service communication for backend systems
- Multi-tenant isolation for SaaS applications
- Model access control for MCP servers
By leveraging OAuth's standardized flows and Descope's implementation, organizations can enforce consistent security policies, simplify credential management, and provide seamless integration experiences for both users and automated systems.