OpenAI Apps SDK authentication exposes new MCP identity control gaps

At a glance

What this is: This is Stytch’s analysis of OpenAI Apps SDK authentication, showing that secure ChatGPT integrations depend on OAuth 2.1, OIDC, MCP metadata, and strict server-side enforcement.

Why it matters: For IAM and NHI practitioners, it shows that the real control boundary is the backend authorisation layer, not the chat UI or built-in consent prompt.

Context

The security problem here is not whether ChatGPT can reach an app. It is whether identity and authorisation controls remain durable once a chat interface can carry user context across sessions, invoke tools, and present approvals inside the conversation.

In this model, the MCP server becomes the control point for scopes, token validation, and write permissions. That shifts the governance question from initial login to ongoing enforcement, because a consent screen is not the same thing as a lifecycle-managed access policy.

For practitioners building NHI-enabled or agent-adjacent workflows, the key issue is that the user-facing experience is now decoupled from the backend policy decision. If the backend does not enforce the right scope and revocation logic, the conversational layer can make access look safer than it is.

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 consent prompts not solve access control in chat-based integrations?

A: Consent prompts capture user intent at one moment, but they do not replace durable access policy. Chat workflows can persist context, reauthorize automatically, and call tools repeatedly across sessions. The control that matters is whether the backend can still enforce revocation, scope boundaries, and token validity after the prompt disappears.

Q: What breaks when tool metadata is treated as the security control?

A: What breaks is the assumption that declared securitySchemes are equivalent to enforcement. Tool metadata helps ChatGPT route requests, but it does not stop a backend from over-trusting the request unless the server rechecks the token, scope, and user claims on every call. The failure is policy drift between description and execution.

Q: How should teams secure sandboxed UI components in MCP integrations?

A: Teams should treat sandboxed components as presentation surfaces only. Give them narrow CSP allowances, keep secrets server-side, and route privileged actions through bearer-token protected tool calls. If a component can reach arbitrary domains or store credentials, the sandbox boundary stops doing useful security work.

Technical breakdown

OAuth 2.1 and OIDC in the Apps SDK

The Apps SDK uses standard OAuth 2.1 and OIDC flows so ChatGPT can act as an OAuth public client on behalf of the user. Discovery metadata, client registration, authorization code with PKCE, token exchange, and JWT validation all remain part of the path, but the identity decision is still enforced by the MCP server. That matters because the chat interface is only the initiator of the flow. The backend remains the protected resource and must treat every tool call as a fresh authorisation event, not as a one-time login side effect.

Practical implication: validate tokens and scopes on every tool call at the server, not in the chat layer.

Tool-level securitySchemes and scope enforcement

The Apps SDK extends MCP with per-tool securitySchemes so each tool can declare whether it is public or protected, and what scopes it requires. That makes tool authorisation explicit and machine-readable, but it does not remove the need for backend enforcement. If a tool can create, update, or delete data, the server still has to reject missing or invalid credentials and issue a standard 401 challenge when reauthorization is needed. The control boundary is therefore the tool execution point, not the front-end description of the tool.

Practical implication: treat tool declarations as metadata, then enforce the declared scope again in code.

Sandboxed components and chat-native UI boundaries

When an Apps SDK component renders inside ChatGPT, it runs in a sandboxed iframe with explicit network allowances defined by CSP. That changes the trust model for front-end code because the component cannot rely on the browser environment it would normally control. It cannot read ChatGPT cookies, and it should never receive bearer tokens directly. Privileged operations must stay behind MCP tool calls, while the UI only handles presentation and user interaction. In identity terms, the front end is now a constrained rendering surface, not an authority plane.

Practical implication: keep credentials server-side and limit component network access to approved domains only.

NHI Mgmt Group analysis

Durable authorisation is the real control plane: The Apps SDK does not eliminate identity governance, it relocates it into the backend policy layer. Chat-based consent is ephemeral, while scopes, token validation, and revocation are durable controls. That means practitioners should judge the architecture by whether the server can still say no after the conversation has moved on.

ChatGPT becomes a public client, not a trust anchor: Once the model is acting as an OAuth public client, the app can no longer assume the conversation itself proves authority. The trust decision must be reconstructed on every request from verified claims and scope state. Teams that let the UX own the security story will overestimate control.

Conversation persistence creates access persistence pressure: The article shows that user context can persist across chats, which is convenient but governance-sensitive. Persistent context increases the chance that teams confuse remembered state with authorised state. The implication is that lifecycle governance now has to account for conversational continuity, not just session start and end.

Tool metadata is not policy enforcement: securitySchemes, consent prompts, and readOnly hints help the model behave, but they do not govern the backend on their own. That separation is healthy only if the server remains authoritative. Practitioners should treat the model-facing layer as a routing aid and the server as the only place where access becomes real.

Identity and UI are now separated by design: Sandboxed components, CSP limits, and bearer-token handling through tools reduce front-end exposure, but they also remove old browser assumptions. The control that mattered in the web era was often what the client could see or store. Here, the control that matters is what the component is never allowed to touch. That is a stronger model only when teams keep it strict.

From our research library:

• 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to the State of Secrets in AppSec.
• Read next: MCP Security Guide

What this signals

Runtime enforcement now outweighs login ceremony: In chat-driven integrations, the important question is whether the backend can still validate claims and scopes after the initial OAuth flow. Consent screens help with transparency, but they do not carry durable policy across repeated tool calls, which is where governance actually lives.

Conversation-aware access is a new governance problem: Persistent user context across chats means teams have to think about authorisation as a continuing state, not a single event. That pushes identity programmes toward revocation discipline, token validation, and server authority rather than front-end trust.

Tool metadata should be read as control signalling, not control assurance: Declared security schemes, read-only hints, and sandbox settings make the integration easier to reason about, but they are only safe when the server reasserts policy. The architecture is trustworthy only when the UI cannot outrun the backend.

For practitioners

• Harden server-side scope checks Require the MCP server to validate OAuth scopes and token claims on every tool invocation, including refresh and reauthorization paths.
• Separate UI state from credentials Keep bearer tokens, refresh tokens, and user identifiers out of widget state and out of sandboxed components.
• Publish and test discovery metadata Expose the protected resource metadata and OIDC discovery documents that ChatGPT needs, then test the full linking flow in developer mode.
• Treat consent as a prompt, not a policy Use built-in write-action confirmations for user visibility, but make the backend enforce durable approval, revocation, and scope boundaries.

Key takeaways

• The Apps SDK shifts identity risk into backend authorisation, where token validation and scope enforcement have to survive across chats and tool calls.
• Consent prompts and sandboxed components improve the user experience, but they do not replace durable policy decisions made by the MCP server.
• Practitioners should treat declarative tool metadata as guidance for the model and enforce access decisions at the server boundary.

Key terms

• MCP Authorization Server: An MCP Authorization Server is the component that decides whether an AI agent or client may access a tool, resource, or action exposed through Model Context Protocol. It evaluates identity, scopes, policies, and consent, then issues or denies authorization decisions and tokens that control what the agent can do.
• Tool-Level Security Scheme: A per-tool declaration that states whether a capability is public or requires authentication and what scopes apply. It helps the client understand intent, but it does not replace backend enforcement, which must still validate the token and permissions before any privileged action runs.
• Sandboxed Component: A user interface component rendered inside a constrained browser context with limited network and storage access. It is designed to isolate presentation from privileged identity state, so bearer tokens and other secrets stay outside the component and remain under server control.
• Durable Authorization: An access decision that remains enforced after the initial login or consent event has passed. For chat-driven integrations, durable authorization means the backend keeps validating scopes, claims, and revocation state on every tool call rather than trusting the conversation context.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.