Glean OAuth Authorization Server

Glean can act as an OAuth 2.1 Authorization Server (issuing access tokens) and as the Resource Server (validating them), while delegating user authentication to your configured Single Sign-On (SSO) Identity Provider (IdP) using OpenID Connect (OIDC) or Security Assertion Markup Language (SAML).

This is currently designed for MCP remote server authentication. While the underlying infrastructure supports Client API operations, full Client API support requires additional UI components that are planned for future releases.

Glean does not replace your SSO. When you enable the Glean OAuth Authorization Server, Glean only acts as the authorization server that issues OAuth access tokens. User authentication continues to happen through your existing SSO Identity Provider (Google Workspace, Microsoft Entra ID, Okta, etc.) using the same OIDC or SAML configuration you already have. Glean reuses your existing SSO for authentication and adds OAuth token issuance on top.

The Indexing API uses a separate authentication model with Glean-issued tokens and does not accept OAuth.

Overview

When to choose this approach

• You are connecting MCP host applications to Glean’s remote MCP server. This is the recommended authentication path for MCP and requires enabling the Glean OAuth Authorization Server.
• You want faster setup without coordinating with your IdP team for new integrations.
• You want Glean-defined, fine-grained scopes for future Client API integrations (note: full Client API support with UI is coming in a future release).

What Glean does and does not do

• Does: Act as OAuth 2.1 Authorization Server (issue access tokens); define and enforce scopes; validate tokens at the Resource Server.
• Does not: Replace or modify your SSO setup. User authentication continues via your existing SSO IdP (OIDC or SAML). Glean reuses your SSO, it doesn’t reinvent it.

Where it applies

• MCP Remote Servers: Fully supported and recommended. This is the primary use case for the Glean OAuth Authorization Server. Note that host OAuth support may vary by MCP client application.
• Client API: Technically supported for operations like search, chat, and agents, but full support requires additional UI components planned for future releases.

Setup and Configuration

Enabling the Glean OAuth Authorization Server

The Glean OAuth Authorization Server is disabled by default. To enable it, follow the steps below:

1. Navigate to OAuth Settings

   Go to the Admin Console and navigate to Settings → Third‑party access (OAuth).

2. Enable Glean OAuth Authorization Server

   

Once the Glean OAuth Authorization Server is enabled, you can start using it immediately, without any additional configuration.

Admins who want to restrict which applications can connect via DCR (e.g. MCP host applications) can configure redirect URI restrictions. See Dynamic Client Registration for details.

Managing static OAuth clients (admin)

Glean supports static OAuth clients that are created and managed by admins.

Static clients are best for:

• Partner integrations that need a stable client_id, redirect URIs, and controlled scopes.
• Customer‑built internal applications or services that call the Client API.

Creating a static OAuth client

1. Navigate to Admin Console → Settings → Third‑party access (OAuth).
2. Choose Create OAuth client (or the equivalent button in the Static applications section).
3. Provide the required details:
   • Application name and (optionally) company name.
   • Redirect URIs (one or more exact, case‑sensitive URIs).
   • Allowed scopes (the operations this client can request).
4. Save the client.
   • Store the secret securely; it cannot be retrieved again later.

Once created, the client can be used by your integration to obtain OAuth tokens from the Glean OAuth Authorization Server.

Updating or rotating a static client

Admins can edit or rotate static clients:

• Edit configuration – Update the name, description, redirect URIs, allowed scopes, or contacts if your integration changes.
• Regenerate client secret – Generate a new secret when credentials are rotated or suspected to be compromised.
  • The old secret is invalidated immediately.
  • Distribute the new secret to any applications that use this client.

User authorized applications

Glean keeps track of which OAuth applications a user has approved so they can review and revoke access later.

At a high level:

• When a user approves an OAuth client, Glean records a consent snapshot for that user and client.
• Users can view the list of authorized applications for their account and see when each application was last used.
• If a user revokes an application:
  • Glean deletes the associated consents and refresh tokens for that user and client.
  • The next time the application tries to use OAuth with Glean, the user will be prompted to sign in and approve access again.

Using OAuth with MCP Remote Servers

Once enabled, MCP host applications can authenticate using the following flow:

• The MCP host initiates the Authorization Code flow (opening a browser for IdP login and user consent)
• The host obtains tokens through the Glean OAuth server
• The host connects to Remote MCP endpoints using the OAuth token
• Bearer token fallback: If an MCP host does not support OAuth, a user-scoped bearer token can be used as a fallback (less preferred than OAuth)

Technical Reference

Supported flows and endpoints

• Authorization Code with Proof Key for Code Exchange (PKCE).
• Endpoints: Authorization, Token, Introspection, and OIDC Discovery. These support standard client registration and token acquisition patterns without exposing non-public base URLs.

Scopes and permissions

Glean-defined scopes govern API capabilities. Request the minimum scopes needed for your integration. Examples include SEARCH, CHAT, AGENTS, MCP, DOCUMENTS, TOOLS, and ENTITIES.

For MCP remote servers, the relevant scopes (particularly MCP and related resource scopes) are automatically managed during the OAuth flow. The Indexing API uses a separate authentication model and does not accept OAuth.

Troubleshooting and cautions

• Ensure the Glean OAuth server is enabled; otherwise token acquisition or validation will fail.
• Redirect URIs must match exactly; the PKCE verifier must match the original challenge.
• Do not use OAuth for the Indexing API, which requires Glean-issued tokens.
• MCP host client authentication failures or unknown client errors: Clear the host’s stored MCP credentials and re-authenticate.

Common OAuth issues

Issue	Possible cause	Resolution
Frequent re‑authentication (every hour)	Access tokens are expiring and the refresh token flow is failing	Verify the OAuth client configuration (client ID/secret, token endpoint) and ensure the integration supports refresh token grants. Re‑authenticate from scratch to obtain a new refresh token.
“Invalid redirect_uri” from identity provider or Glean	Redirect URI configured in the OAuth client does not exactly match the URI used in the flow	Confirm the redirect URI in the OAuth client configuration matches the callback URL used by your integration, including scheme, hostname, path, and case. Update either the client or the integration so they match.
Unknown client or authentication failure for an integration that used to work	Static client was deleted or had its secret rotated without updating the integration	In the Admin Console, verify that the static client still exists and is enabled. If the secret was regenerated, update the integration with the new client configuration or create a new static client.

Related links

• Back to Overview
• Dynamic Client Registration
• IdP-based OAuth
• Client API authentication overview
• OAuth (IdP tokens) developer guide
• MCP Remote Server (overview/host configurator)
• MCP Server setup (admin enablement context)