Skip to content
Tallyfy

Using SSO with MCP servers

Sign in once, use every AI tool

Section titled “Sign in once, use every AI tool”

If your company already uses single sign-on1 (SSO) - the “log in with your company account” button you see for email and other apps - your team can use that same login for Tallyfy’s AI tools. Sign in once, and every approved tool just works. No separate password per tool. No secret keys to copy around.

Here’s why that matters. Say someone uses Tallyfy alongside their email, calendar, and a couple of other connected tools. Without SSO, each one is its own login. With SSO, it’s one login your IT team controls. And they can switch it off in one place the day someone leaves.

This is an advanced setup. Your IT team turns it on, usually with a developer’s help. The technical details are further down this page.

What you get

Section titled “What you get”
  • One company login across all approved AI tools (the same one people already use).
  • Central control for IT: approve tools, see who’s connected, and cut off access when someone leaves.
  • Your existing security rules, like requiring a second step to log in, apply automatically.

Which logins Tallyfy works with

Section titled “Which logins Tallyfy works with”

Tallyfy’s AI connection works with the major company-login providers:

  • Microsoft Entra ID (formerly Azure AD)
  • Okta
  • Google Workspace
  • OneLogin and most other providers that follow the usual sign-in standards

Setup differs a little for each one. Your IT team will find the specifics in the technical section below.

A couple of honest limits

Section titled “A couple of honest limits”
  • You’ll sometimes still approve a tool the first time you connect it (one prompt per tool).
  • Logins from different providers don’t always share a single sign-in behind the scenes, so some connections need their own setup.

For your IT team

Section titled “For your IT team”

(Skip this unless you’re setting up the technical side.)

What Tallyfy’s MCP server already supports

Section titled “What Tallyfy’s MCP server already supports”

Tallyfy’s MCP server already implements OAuth 2.1 with PKCE S256, Dynamic Client Registration (RFC 7591), and authorization server metadata discovery (RFC 8414). Tokens are RS256-signed JWTs with the public key at /.well-known/jwks.json. The well-known endpoint at /.well-known/oauth-authorization-server lets AI clients like ChatGPT and Claude Desktop discover OAuth endpoints automatically. Scopes use dot notation, for example mcp.tasks.read, mcp.processes.write, and mcp.templates.read. The server is listed on the Official MCP Registry ↗ as com.tallyfy/mcp-server.

Token resource binding (mcp_resource claim) - Access tokens carry a canonical mcp_resource claim that pins the token to a specific MCP resource URL (the server endpoint it was issued for). The server uses this claim to detect and reject tokens replayed against a different resource. For backwards compatibility with legacy Passport-issued tokens (which use aud: 1), the server also accepts tokens that lack mcp_resource but present the expected legacy audience, so existing integrations keep working while new clients get the stricter binding.

The authentication challenge in MCP

Section titled “The authentication challenge in MCP”

MCP servers don’t know who you are by default. They receive requests from AI agents with no identity or context. This creates gaps when accessing enterprise systems that need user credentials.

Common workarounds and their problems:

  • Embedding API keys as environment variables - doesn’t scale
  • OAuth Device Authorization Flow for local servers - clunky UX
  • Manual token management per tool - shadow IT risk and compliance headaches

How SSO bridges the gap

Section titled “How SSO bridges the gap”

SSO integration with MCP uses OAuth 2.1 flows that delegate authentication to enterprise identity providers.

The login flow, step by step

Section titled “The login flow, step by step”
  1. User initiates connection - AI agent requests access to a tool
  2. SSO redirect - MCP server redirects user to corporate identity provider
  3. Corporate authentication - user logs in with SSO credentials (including MFA)
  4. Token exchange - identity provider returns an authorization code, which the MCP server exchanges for an access token
  5. API access - MCP server uses the token to call service APIs

This diagram shows how SSO authentication flows between users, AI agents, MCP servers, and identity providers.

SSO Authentication Flow with MCP

What to notice:

  • Steps 4-5: The identity provider validates corporate credentials including MFA and conditional access policies before issuing tokens
  • Steps 8-9: The MCP server handles token exchange automatically - users never see raw tokens
  • Steps 10-13: Once authenticated, the MCP server can make multiple API calls on behalf of the user without further prompts

Accepting existing SSO tokens

Section titled “Accepting existing SSO tokens”

Advanced implementations let MCP servers accept existing SSO tokens directly:

  • AI client presents a valid OIDC ID token or access token from the identity provider
  • MCP server verifies token authenticity and extracts user permissions
  • Server performs token exchange to get service-specific API credentials
  • Already-authenticated users skip additional login prompts

Which identity providers work, in detail

Section titled “Which identity providers work, in detail”

Microsoft Entra ID (Azure AD)

Section titled “Microsoft Entra ID (Azure AD)”
  • Full OAuth 2.1 and OIDC support with PKCE
  • On-behalf-of (OBO) token exchange for Microsoft Graph APIs
  • Conditional Access Policies apply automatically to MCP connections
  • Native integration with Microsoft 365 and Azure services

Limitations: Tokens are designed primarily for Microsoft APIs. No native cross-provider token exchange. Each MCP server must be registered as an app manually.

Okta

Section titled “Okta”
  • OAuth 2.0 with device flow support
  • Custom authorization servers for API-specific scopes
  • Dynamic client registration and flexible token refresh
  • Okta Integration Network (OIN) listing for one-click deployment
  • SCIM provisioning for automated user management

Discovery: Okta supports both /.well-known/openid-configuration and /.well-known/oauth-authorization-server (RFC 8414). The RFC 8414 endpoint is the standard for pure OAuth 2.0 flows.

Google Workspace Identity

Section titled “Google Workspace Identity”
  • OAuth provider for Google services (Gmail, Drive, Calendar) and OIDC identity provider for third-party apps
  • Domain-wide delegation lets admins pre-authorize applications and service accounts
  • Admin-managed app whitelisting and Google Workspace Marketplace integration

OneLogin and other providers

Section titled “OneLogin and other providers”

Most enterprise identity providers offer SAML 2.0 and OIDC/OAuth 2.0 compatibility with similar token exchange limitations and marketplace integration options.

Current gaps and challenges

Section titled “Current gaps and challenges”
Section titled “Repeated consent fatigue”

Users face multiple OAuth consent flows for each tool integration, even when using the same SSO credentials. An employee with email, calendar, Slack, GitHub, and Salesforce integrations hits five separate login prompts.

Shadow OAuth visibility

Section titled “Shadow OAuth visibility”

Token exchanges between AI applications and services often happen outside IT’s oversight. There’s no centralized view of which apps access which data for which users, making offboarding and access revocation difficult.

Implementation complexity

Section titled “Implementation complexity”

Each MCP server developer must implement OAuth components (authorization endpoints, token management, client registration). Building secure OAuth flows requires specialized knowledge, and mistakes introduce vulnerabilities.

Token lifecycle management

Section titled “Token lifecycle management”

Coordinating token refresh, expiration, and revocation across multiple identity domains remains hard. There’s no universal token exchange between providers, and revocation signals don’t propagate consistently.

Solution approaches

Section titled “Solution approaches”

Centralized profile system

Section titled “Centralized profile system”

A cloud service acts as a universal integration broker, similar to mcp.run’s profile system ↗. Users connect tools once on a dashboard, group them into profiles, and AI applications request access to the whole profile through a single OAuth flow.

The bridge service becomes the OAuth Authorization Server, storing encrypted API credentials in a token vault, routing MCP requests to appropriate services, and providing centralized audit logging.

Enterprise IdP extensions

Section titled “Enterprise IdP extensions”

An add-on for existing identity providers handles inter-application authorization. When an AI application needs a Slack token, it asks the mediation service, which validates the user’s identity with the corporate IdP, checks admin policies, and returns the token, all without user interaction.

This gives admins a dashboard for approving or denying AI-to-app connections with centralized policy enforcement and audit trails.

Developer SDK approach

Section titled “Developer SDK approach”

Pre-built SDKs make OAuth manageable for MCP server developers by providing integrations for major identity providers, automatic token refresh, and consistent security patterns.

Implementation strategies

Section titled “Implementation strategies”

OAuth 2.1 standard compliance

Section titled “OAuth 2.1 standard compliance”

Tallyfy’s MCP server already follows these OAuth 2.1 patterns. Here’s what any MCP implementation needs:

  1. Use PKCE for all flows

    PKCE protects against authorization code interception. Tallyfy requires S256 code challenge method - no plain text allowed.

  2. Implement metadata discovery

    Expose /.well-known/oauth-authorization-server per RFC 8414. This lets AI clients discover authorization, token, and registration endpoints automatically.

  3. Enable dynamic client registration

    RFC 7591 support lets AI applications register with MCP servers programmatically. Tallyfy’s DCR endpoint validates redirect URIs and blocks localhost domains.

  4. Plan for token exchange

    OAuth 2.0 Token Exchange (RFC 8693) enables on-behalf-of scenarios. Tallyfy implements refresh token rotation with reuse detection to protect against stolen tokens.

Security considerations

Section titled “Security considerations”

Token storage: Use encrypted key vaults, short-lived access tokens with refresh mechanisms, and monitor for unusual API usage patterns.

Network security: Require HTTPS for all authentication endpoints. Tallyfy’s MCP OAuth endpoints include rate limiting - 5 registrations per hour for DCR, 60 token requests per minute.

Access control: Map SSO roles to MCP tool permissions using scopes like mcp.tasks.read and mcp.processes.write. Support conditional access policies from identity providers.

Best practices for enterprises

Section titled “Best practices for enterprises”

Governance and compliance

Section titled “Governance and compliance”

Define approved AI applications and integrations. Document data access requirements. Log all token exchanges and API access, and schedule regular permission audits.

User experience optimization

Section titled “User experience optimization”

Minimize authentication friction by using existing SSO sessions. Group related tools into logical profiles. Support different client types - web apps use authorization code flow, desktop apps use device authorization flow, and CLI tools use client credentials or device flow.

Technical architecture

Section titled “Technical architecture”

Cache tokens to reduce identity provider load. Implement circuit breakers for external API calls and design graceful degradation when identity services go down.

Section titled “Integration with popular providers”

Microsoft identity providers

Section titled “Microsoft identity providers”

Register as an Enterprise Application in Azure AD Gallery. Use Entra ID authentication for Copilot Studio connectors - enterprise security controls apply automatically.

Okta Integration Network

Section titled “Okta Integration Network”

Submit through OIN: create an integration in Okta’s developer org, implement OIDC flow, add SCIM provisioning if applicable, then submit for certification. Okta customers get one-click configuration.

Google Workspace Marketplace

Section titled “Google Workspace Marketplace”

Requires OAuth application verification, privacy policy documentation, and minimal scope usage. Domain-wide installation gives admins centralized permission management.

What’s changing

Section titled “What’s changing”

The OpenID Foundation is developing cross-domain authorization chaining standards. OAuth 2.0 extensions will enable more flexible cross-provider token exchange. AI-specific authentication protocols are also in development.

The trend is moving toward user-controlled integration profiles that travel between AI applications, zero-trust architecture integration, and stronger audit trails for regulatory compliance.

Section titled “Related articles”

Footnotes

Section titled “Footnotes”

  1. Single sign-on. One company login (Entra ID, Okta, Google Workspace) unlocks every approved app, so people don’t manage a password per tool. ↩

Get in touch
About Tallyfy