Glean supports OAuth 2.0 (OAuth) for authenticating requests to the Client API and for connecting Model Context Protocol (MCP) host applications to Glean’s Remote MCP Servers. This guidance does not apply to the Indexing API.
Where OAuth applies at Glean
- Client API: OAuth is supported for REST access to search, chat, agents, and related endpoints.
- Remote MCP Servers: OAuth is supported and recommended. Use bearer token fallback only if the host application cannot perform OAuth.
- Indexing API: OAuth is not supported. The Indexing API uses a different authentication mechanism with Glean-issued tokens.
Supported OAuth variants
- IdP-based OAuth (Authorization Code): Use access tokens issued by your enterprise Identity Provider (IdP) such as Google Workspace, Microsoft Entra ID/Azure AD, Okta, or OneLogin. Best fit for REST integrations when you already operate OAuth in your IdP. See OAuth with IdP‑issued tokens.
- Glean OAuth Authorization Server (Authorization Code + PKCE; DCR for MCP): Glean issues OAuth tokens with Glean-defined scopes to users logged in to Glean. If necessary, users are seamlessly directed to log in with your SSO provider as part of the authorization process.. Recommended for new REST integrations and required by the recommended MCP path. See Glean OAuth Authorization Server.
Proof Key for Code Exchange (PKCE) is an OAuth 2.0 extension (and required in OAuth 2.1) to prevent authorization code injection attacks. Learn more.
Dynamic Client Registration (DCR) is an OAuth 2.0 extension to simplify connecting to OAuth-protected servers. Learn more.
Which OAuth approach should you choose?
| Consideration | Glean OAuth Authorization Server | IdP-based OAuth |
|---|
| Setup complexity | Simple. Configure entirely within Glean Admin Console. | Complex. Requires registering OAuth app in your IdP, then configuring Glean to accept those tokens. |
| Who needs to be involved | Only Glean admins. | Glean admins + IdP admins. If you don’t manage your IdP directly, expect coordination delays. |
| Time to get started | Fast. Enable in Admin Console and register client apps immediately. | Slower. Depends on IdP team availability and approval processes. |
| Best for | New integrations, MCP connections, when you want quick deployment. | Existing OAuth infrastructure, centralized token governance, strict enterprise policies requiring all OAuth through IdP. |
| MCP support | Required for MCP Remote Servers (with DCR support). | Not suitable for MCP. |
| Token lifecycle | Managed by Glean. Issuance, expiry, and refresh handled by Glean’s OAuth server. | Managed by your IdP. Aligns with existing enterprise token policies. |
| Scopes | Fine-grained Glean-defined scopes (SEARCH, CHAT, AGENTS, MCP, etc.). | User-scoped permissions; Glean enforces access based on user identity. |
| User authentication | Glean does not replace your SSO. Users authenticate via your existing SSO IdP (Google, Entra, Okta, etc. using OIDC/SAML). Glean reuses your existing SSO configuration and only issues OAuth access tokens after successful authentication. No changes to your SSO setup required. | Users authenticate via your IdP’s OAuth flow. |
Recommendation: Use Glean OAuth Authorization Server unless you have a specific requirement to centralize all OAuth token issuance in your IdP or existing IdP-based OAuth applications you want to extend to Glean.
What’s supported vs. not supported
| Category | Supported | Not supported |
|---|
| Grant types | Authorization Code with PKCE (OAuth 2.1 compliant) | Implicit; Resource Owner Password Credentials (ROPC) |
| Client API auth | HTTP Bearer tokens (OAuth access tokens) with required headers | OAuth for Indexing API |
| MCP Remote Servers | OAuth via Authorization Code; DCR where host supports it; bearer token fallback if host cannot do OAuth | |
Quick reference
Once you’ve chosen your approach using the decision matrix above:
