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:

1. Allow companies to integrate their own identity providers
2. Ensure users from different tenants cannot access each other's data
3. 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

1. Applications register as OAuth clients, defining required scopes
2. Users authorize access through consent screens
3. OAuth tokens are issued with specific permissions
4. 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

Unlike user-centric authentication, machine-to-machine scenarios rely on the OAuth client credentials flow:

curl -X POST "https://api.descope.com/oauth2/v1/apps/token" \
  -d "grant_type=client_credentials" \
  -d "client_id=your-client-id" \
  -d "client_secret=your-client-secret" \
  -d "scope=api.read api.write"

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:

1. Allow end-users to log in using the same Descope flows as the web app.
2. Store an access token and refresh token locally for API calls.
3. 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.

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.