OpenAI Apps SDK authentication exposes new MCP identity control gaps

At a glance

What this is: Stytch’s guide explains how the OpenAI Apps SDK uses OAuth 2.1, OIDC, and MCP to connect ChatGPT to external apps with scoped access, consent, and server-side enforcement.

Why it matters: It matters because identity teams now have to govern user-facing chat integrations as delegated access paths, with the same scrutiny they apply to API clients, session handling, and privileged tool calls.

👉 Read Stytch's guide to OpenAI Apps SDK authentication and MCP

Context

OpenAI Apps SDK authentication for MCP integrations turns ChatGPT into a delegated client that can act on behalf of a user, which changes the identity boundary even when the application logic stays familiar. The governance problem is not simply whether a token is valid, but whether scopes, consent, and server-side enforcement still hold when a conversational interface can persist context across chats.

For IAM and NHI teams, the important shift is that the protected resource is no longer only a traditional web app or API. The auth layer must now account for tool-level authorization, reauthorization, sandboxed UI components, and persistent user context, all while keeping secrets out of the client and treating the MCP server as the final gatekeeper.

Key questions

Q: How should teams secure ChatGPT apps that use MCP and OAuth?

A: Teams should treat the MCP server as the trust boundary, then enforce OAuth 2.1 and OIDC on every privileged tool call. Discovery metadata, client registration, consent, and token validation matter, but none of them replace server-side scope checks. If the tool can change data, the backend must verify the token before execution.

Q: Why do chat-based app integrations change identity governance requirements?

A: They turn a conversational interface into a delegated client that can persist context and reuse access across sessions. That means governance must cover token lifetime, scope precision, reauthorization, and offboarding, not just interactive login. The access path behaves more like an ongoing delegated relationship than a single user session.

Q: What do teams get wrong about securitySchemes in MCP tools?

A: They often treat securitySchemes as a complete control, when it is really just metadata that describes required access. The server still has to validate the token, enforce the declared scope, and fail closed if the caller is missing permission. Without backend checks, tool declarations become documentation instead of enforcement.

Q: What is the difference between sandboxed components and tool authorization?

A: Sandboxing restricts what the component can see and which domains it can reach, while tool authorization decides whether the backend should perform the action at all. A safe iframe does not make a privileged tool safe. The browser boundary controls exposure; the server boundary controls authority.

Technical breakdown

OAuth 2.1 and OIDC in MCP tool access

The Apps SDK uses OAuth 2.1 for delegated authorization and OIDC for identity assertions, with ChatGPT operating as a public client and the application backend acting as the protected resource. Discovery metadata, authorization endpoints, token exchange, and client registration let the chat interface obtain scoped access without inventing a new identity protocol. The critical detail is that the model does not become the authority. The MCP server still validates the token, enforces scopes, and decides whether the tool call can proceed.

Practical implication: treat the MCP server as the enforcement point, not the chat interface.

SecuritySchemes and tool-level authorization

SecuritySchemes let each MCP tool declare whether it requires authentication and which scopes are needed. That matters because chat-driven workflows often mix public and protected actions in the same interface, and a tool can look harmless while still mutating data or exposing private context. The pattern is closer to fine-grained API authorization than to a single login gate. If the tool requires a write scope, the server must verify it on every request and fail closed when the token is missing, expired, or under-scoped.

Practical implication: inventory tools by action risk, then bind each one to explicit scopes and server-side checks.

Sandboxed components and credential containment

When the Apps SDK renders a component, it runs inside a sandboxed iframe with a declared content security policy. That limits which domains the component can contact and prevents it from reading ChatGPT cookies or handling privileged credentials directly. This is a useful containment model, but it also creates a sharper boundary around what the frontend may see versus what the backend may do. Credentials belong in bearer-token tool calls, not in component state or client-side scripts.

Practical implication: keep secrets and privileged logic in the backend, and restrict widget connectivity to approved domains.

NHI Mgmt Group analysis

Persistent chat context creates an identity review blind spot: The article assumes that a user’s connection to ChatGPT can persist across chats, which means access is no longer reviewed only at login time. That assumption is safe for ordinary web sessions, but it becomes fragile when a conversational interface can keep acting through a durable delegated path. Practitioners should treat this as a lifecycle and review problem, not just a login problem.

Tool-level scopes are the right control surface, but only if they remain server-enforced: Declaring securitySchemes in MCP is useful because it makes each tool’s access profile explicit. The governance failure mode appears when teams treat those declarations as sufficient on their own. Scope metadata is descriptive; the backend still has to validate tokens and deny actions that fall outside the approved boundary.

Sandboxing reduces frontend exposure, not identity risk: The component iframe and CSP model help contain browser-side leakage, but they do not remove the need to govern delegated access, token lifetimes, and write-action consent. The architectural boundary is useful only if teams keep a strict separation between UI state and authorization state. Identity programmes should therefore review chat-integrated apps as distributed access paths, not as simple embedded widgets.

OAuth-backed chat integrations extend NHI governance into human-mediated automation: ChatGPT is not an autonomous actor in this article, but it does become a high-leverage delegate that can invoke tools repeatedly on behalf of a human. That places these integrations squarely in the overlap between human IAM, workload-style token handling, and NHI-style service enforcement. Security teams should govern them as privileged delegated clients with durable operational impact.

Open standards reduce lock-in, but they do not reduce accountability: The guide correctly leans on OAuth 2.1, OIDC, and MCP metadata rather than custom protocols. That improves interoperability, yet it also raises the bar for lifecycle discipline because teams can no longer hide behind bespoke exceptions. The practical conclusion is simple: if the identity path is standards-based, the governance model must be standards-based too.

From our research:

• 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation, according to Ultimate Guide to NHIs.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
• For a broader identity baseline, the Ultimate Guide to NHIs , Key Challenges and Risks covers visibility, over-privilege, and unmanaged credentials.

What this signals

Delegated chat access is becoming an identity governance problem, not just an application integration problem: once a conversational client can persist context and invoke tools on behalf of a user, programmes need lifecycle controls that extend beyond login and session management. The governance lens should move from who authenticated to what delegated access remains active, what scopes it can exercise, and how quickly it can be revoked.

Persistent consent and server-enforced scope checks are the practical fault line: organisations that already struggle with offboarding and revocation will feel that pain more sharply in chat-integrated workflows. The operational lesson is to align MCP tool access with the same discipline used for service accounts, because the access pattern is still delegated and still requires lifecycle ownership.

For practitioners

• Map each MCP tool to a specific access class Classify tools as public, read-only, or write-capable, then require explicit scopes for any tool that touches private data or changes state. Recheck that classification whenever the tool surface expands or the chat experience starts reusing user context across sessions.
• Validate tokens on every server-side call Treat the MCP server as the final gatekeeper for authorization and reject requests that lack valid issuer, audience, expiry, or scope claims. Do not let the chat layer, UI sandbox, or client-side logic substitute for server enforcement.
• Separate UI state from identity state Keep widget state limited to presentation details and store credentials, refresh logic, and account linkage in the backend. If a component needs to show private data, have it request that data through a token-checked tool call rather than embedding secrets in the browser context.

Key takeaways

• MCP-based chat integrations extend identity governance into delegated, session-persistent tool use, which makes scope control and revocation more important, not less.
• SecuritySchemes improve clarity at the tool layer, but the backend remains the only authoritative place to validate tokens and enforce privilege.
• Sandboxed components reduce frontend exposure, yet they do not remove the need for NHI-style lifecycle discipline around tokens, consent, and access review.

Key terms

• MCP authorization server: The MCP authorization server is the identity and policy endpoint that issues and validates access for tools exposed through a ChatGPT integration. It publishes discovery metadata, accepts authentication requests, and serves as the source of truth for scopes and token checks.
• SecuritySchemes: SecuritySchemes are tool-level declarations that describe whether an MCP tool requires authentication and which scopes it needs. They improve machine readability, but they do not enforce access by themselves, so the backend must still validate every request before action is taken.
• Delegated client: A delegated client is an application or platform that performs actions on behalf of a user after receiving permission. In this context, ChatGPT acts as a delegated client, which means governance must cover consent, token scope, and revocation across the full access path.
• Sandboxed iframe: A sandboxed iframe is an isolated browser container that restricts what embedded UI can access or load. It reduces exposure of cookies, scripts, and network destinations, but it does not grant or replace authorization to perform privileged backend actions.

What's in the full article

Stytch's full article covers the implementation detail this post intentionally leaves at the governance layer:

• Discovery document fields, authorization endpoints, and protected resource metadata for MCP integrations
• FastMCP and JWT verification examples for server-side token handling across tool calls
• SecuritySchemes JSON and Python patterns for declaring read-only versus write-capable tools
• Consent, reauthorization, and sandbox configuration details for building the end-to-end ChatGPT integration

👉 Stytch's full post covers token validation, securitySchemes, and sandboxed UI configuration in detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.