This section explains how the OpenEdge MCP Server processes requests under different conditions. Each sequence diagram illustrates the interaction between components and the security measures applied during the request lifecycle.

Normal request flow

The following image represents a standard successful request flow.

It includes:
  • Tool discovery by the MCP Client.
  • Invocation of a selected tool.
  • Dual authentication and scope validation.
  • Guarded downstream call to PAS for OpenEdge services.
  • Return of a bounded response to the client.

Token exchange variant

This scenario follows the normal execution path but introduces a token exchange step.

The MCP Server issues a scoped backend token instead of passing the original user token downstream. This approach improves isolation and reduces the credential blast radius by enforcing tighter token lifetimes and scopes.

Authentication failure and retry

This scenario demonstrates fail-closed behavior, which is a security best practice: instead of allowing a fallback or partial access, the MCP Server blocks the operation and requires the user to retry with valid credentials.

  • The request fails if the service account credential is missing or invalid.
  • Recovery occurs immediately after a valid service account token is provided.

Rate limit denial

This scenario shows how the MCP Server enforces throughput policies.

The MCP server:
  • Rejects an over-quota request before any downstream call.
  • Returns metadata so that the client can apply backoff strategies.

Token exchange: With and without

The following comparison table highlights the differences between using token exchange and passing the original user token:
  • Without exchange—The original user token is sent downstream.
  • With exchange:—The MCP Server issues a scoped token with controlled lifetime and claims.
Table 1. Token Exchange: With vs Without
Aspect Without Exchange With Exchange
When used Direct user token acceptable by PAS for OpenEdge services Backend requires different audience, specific claims, or shorter time to live (TTL).
Extra network round trip No additional network call is needed Adds one call to PAS for OpenEdge SSO endpoint per exchange. This step is often optimized through token caching based on TTL.
Credential sent downstream The original user token is forwarded to PAS for OpenEdge Services. The MCP server issues a scoped exchanged token (T_out), which is sent downstream to ensure tighter control.
Token lifetime and scope control Lifetime and scope are determined solely by the upstream Identity Provider. The MCP server enforces stricter limits on token lifetime, audience, and scopes for backend usage.
Failure mode The downstream call proceeds unless the token is invalid. Exchange failure aborts request (fail closed), preventing fallback to the original user token.
Security benefit Provides simplicity and lower latency because no additional configuration or network round trip is required. Enhances security by reducing the blast radius and preventing exposure of raw user tokens with excessive scopes.
Operational complexity Lower complexity since no token exchange configuration is needed. Higher complexity due to additional setup for token exchange endpoints, certificate authority trust, and retry handling.
Recommended use Suitable for development environments or deployments with homogeneous trust boundaries. Recommended for production environments that require stricter backend security or multi-tenant isolation.