Notifications
Clear all
Topic starter
11/07/2026 8:38 pm
TL;DR: The OpenAI Apps SDK uses OAuth 2.1, OIDC, and MCP to let ChatGPT connect to apps with scoped tool access, built-in consent, token validation, and sandboxed components, according to Stytch. The real governance issue is not connectivity but whether teams can enforce durable authorization, user context, and server-side control across chat-driven workflows.
NHIMG editorial — based on content published by Stytch: Guide to authentication for the OpenAI Apps SDK Auth & identity
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
- 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.
- Separate UI state from identity state Keep widget state limited to presentation details and store credentials, refresh logic, and account linkage in the backend.
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
👉 Read Stytch's guide to OpenAI Apps SDK authentication and MCP →
OpenAI Apps SDK auth and MCP: are identity controls keeping up?
Explore further
11/07/2026 9:06 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: OpenAI Apps SDK authentication exposes new MCP identity control gaps
