September 2026 Summaries

OpenID Connect (OIDC) is an identity layer built on OAuth 2.0 that enables applications to authenticate users through an identity provider such as Google, Okta, or Microsoft, returning a standardized signed JWT ID token that identifies the user. Unlike OAuth, which authorizes an application to access APIs on a user’s behalf through access tokens, OIDC answers who the user is and standardizes identity claims, discovery endpoints, and login flows. The recommended implementation is the Authorization Code flow, using PKCE for single-page and mobile applications, in which applications redirect users to an identity provider, receive a temporary code, exchange it securely for tokens, and validate the ID token’s signature, issuer, audience, expiration, nonce, and subject claim. OIDC generally offers a simpler, more modern alternative to SAML, particularly for social login, mobile, and SPA use cases, although many enterprise products support both because SAML remains common in established corporate identity systems. The discussion emphasizes security practices such as using the stable subject identifier rather than email, checking verified email claims, using discovery documents and rotating signing keys, validating state to prevent CSRF, and avoiding the deprecated Implicit flow. It also distinguishes authentication from account provisioning, which is handled through SCIM, and describes enterprise SSO platforms such as PropelAuth as tools for managing per-customer identity-provider configuration, organization membership, roles, sessions, and SAML/OIDC interoperability.

PropelAuth argues that enterprise MCP authorization should be governed centrally rather than left solely to individual users who connect AI clients such as Claude, ChatGPT, or Cursor. Its organization scopes restrict access to shared organizational resources according to existing product roles, allowing only authorized roles such as Owners or Admins to grant sensitive permissions, while still permitting lower-privileged users to access appropriate tools. Enterprise SSO integrates MCP authentication with customer identity providers such as Okta or Microsoft Entra ID, applying existing sign-in policies, role mappings, group changes, and offboarding processes to AI connections. MCP servers can validate tokens for granted scopes, organization identity, and user roles, while audit logs record client creation, consent changes, and revocations. The approach emphasizes least privilege through individually selectable scopes, recommends separate scopes for sensitive capabilities such as billing or customer-data export, and positions centralized, role-based, auditable AI access as an increasingly important enterprise security requirement.

OAuth consent screens are increasingly important as AI clients such as Claude, ChatGPT, and Cursor can register dynamically through DCR or CIMD without prior manual vetting, making the screen the user’s primary opportunity to assess an access request. Effective screens should clearly identify the signed-in account, let users selectively approve optional scopes while displaying required or disallowed ones, enforce those choices in issued tokens and resource checks, and show the validated redirect destination. Localhost or native-app redirects require contextual warnings that help users confirm they initiated the request without treating them as inherently malicious. For CIMD clients, a client’s domain should be treated as its identity while its display name and logo remain unverified claims unless the publisher is recognized, helping expose impersonation and look-alike domains. Consent should be requested again when privileges expand or scope meanings change, and B2B products should additionally specify the organization receiving access and restrict available permissions according to the user’s organizational role.

PropelAuth has added support for Client ID Metadata Documents (CIMD), the MCP authorization specification’s recommended alternative to Dynamic Client Registration (DCR). CIMD lets AI clients identify themselves through a URL-hosted JSON metadata document containing details such as the client name, redirect URIs, grant types, and authentication method, allowing PropelAuth to validate the client’s identity and requested redirect URI without requiring pre-registration or an Allowed MCP Clients entry. This approach addresses DCR’s limitation of allowing unverified clients to create authorization-server records, while preserving automatic, low-friction client setup. PropelAuth advertises CIMD support through its authorization server metadata and continues to support manual client creation and DCR for compatibility with older clients. Administrators can enable CIMD with a dashboard toggle, while scopes, sessions, token introspection, and audit logging continue to function as they do for other MCP OAuth clients.

PropelAuth has introduced a Default Resource setting for MCP Authentication to support OAuth 2.0 clients such as Microsoft Copilot Studio that do not send the resource parameter required by the MCP authorization specification. When enabled, the setting substitutes a configured MCP server URL for missing resource values, allowing authorization to proceed while keeping issued tokens audience-bound to that specific server; clients that supply a resource parameter continue to work unchanged. The feature is intended only for environments with one MCP server and should remain disabled when all clients are MCP-compliant or when multiple servers share an authorization environment, since selecting a default resource would be ambiguous. The change addresses a practical compatibility gap between generic OAuth 2.0 integrations and MCP’s OAuth 2.1-based authorization requirements, particularly RFC 8707 resource indicators, which protect against tokens being used with unintended servers. Administrators can enable the option in PropelAuth’s dashboard, configure the server’s canonical URL, and retain existing protections such as PKCE, scope consent, redirect URI controls, and token introspection.