User Connector Authentication for Headless Integrations
When you use Glean in a headless way (custom UI, Web SDK, or API-only), users still need to authorize certain connectors (for example, Slack RTS, GitHub) so Glean can access their private data on their behalf.
Choosing the right approach
Use this mapping to decide which option to implement based on how your users access Glean:
| Cohort | How users access Glean | Recommended option | Status |
|---|---|---|---|
| A | Users can log into the Glean web app (app.glean.com or <vanity>.glean.com) | Option 1: Glean UI | Available now |
| B | Users interact with Glean through an embedded Web SDK experience | Option 2: Web SDK settings component | Available now |
| C | Users interact with Glean entirely through your own custom UI built on the Client API | Option 3: checkdatasourceauth API | Available now |
All three options drive the same underlying per-user OAuth state. You can mix them as needed — for example, using Option 1 for admins who are comfortable in the Glean web app and Option 3 for a fully custom "Connect apps" page in your product.
Option 1: Glean UI connectors page
Users with access to the Glean web app Admin console can authorize per-user connectors directly in the Glean UI. In Admin Console → Connectors, users can see which connectors need authentication and which are already connected.
What users do
Users can do the following to authorize per-user connectors:
- Sign in to Glean in the browser (via SSO or other configured auth).
- Open Admin Console → Connectors.
- Find sources such as Slack (RTS) or GitHub and click Connect or Authorize.
- Complete the OAuth consent flow with for the selected connector provider.
Why this is preferred
- No engineering integration work is needed.
- Works for search, chat, and any API clients that act as that user.
- Handles Slack RTS and other per-user sources automatically once the user has authorized them.
Option 2: Web SDK settings component
It is possible for browser security features to prevent the OAuth popup from informing the SDK that a user has successfully authenticated. For the highest reliability, use the Glean web app or the checkdatasourceauth API
If you already embed Glean using tools directly in your application.
Use this when
- You have a first-class user settings or integrations page in your product.
- You want a drop-in UI for per-user auth without sending users to the Glean web app.
- You're fine using Glean's UX patterns (labels, flows) in your interface.
High-level integration
- Initialize the Web SDK using your existing authenticaiton mechanism so Glean can identify the current user.
- Mount the connectors component on your Search settings or Connect apps page. It lists per-user connectors that need auth for the active user and shows Connect and Authorize tools for each.
- When the user clicks Connect, the Web SDK starts the appropriate OAuth flow (for example, Slack or GitHub) and handles redirects and token storage via Glean.
- After completion, the component refreshes and marks the source as connected.
Option 3: checkdatasourceauth API
For API-only or highly customized headless integrations, you can call the Client API to discover which connector instances require per-user OAuth, then build your own UI around that.
See the Glean developer documentation for examples of using this API to render a page where users can authorize their connectors.
Endpoint
| Field | Value |
|---|---|
| Method | POST |
| Path | /rest/api/v1/checkdatasourceauth |
| Base URL | https://tenant_id-be.glean.com |
| Auth | Bearer Client API token for the authenticated user or service |
Copy your full backend URL from app.glean.com/admin/about-glean under Server instance (QE), and replace https://tenant_id-be.glean.com with it.
Response
The endpoint returns a CheckDatasourceAuthResponse containing an array of unauthorizedDatasourceInstances. Each entry includes:
| Field | Description |
|---|---|
datasourceInstance | Instance identifier (e.g. slack_0, github_enterprise_0) |
displayName | Human-readable name (e.g. "Slack") |
authStatus | Current per-user auth status: DISABLED, AWAITING_AUTH, AUTHORIZED, STALE_OAUTH, or SEG_MIGRATION |
authUrlRelativePath | Relative OAuth URL for this user + instance, including a one-time transient token |
Example response
{
"unauthorizedDatasourceInstances": [
{
"datasourceInstance": "slack_0",
"displayName": "Slack",
"authStatus": "AWAITING_AUTH",
"authUrlRelativePath": "/auth/slack/oauth?transient_auth_token=..."
}
]
}
Example request
curl -X POST \
"https://$GLEAN_INSTANCE-be.glean.com/rest/api/v1/checkdatasourceauth" \
-H "Authorization: Bearer $GLEAN_API_TOKEN" \
-H "Accept: application/json"
GLEAN_INSTANCEis your tenant instance ID (e.g.acme).GLEAN_API_TOKENis a Client API token that authorizes calls on behalf of the user.
Build your own "Connect apps" UI
A typical headless flow:
- Call
checkdatasourceauthas the current user. - For each item in
unauthorizedDatasourceInstances, render tools such as Connect Slack or Connect GitHub, and build the full OAuth URL ashttps://tenant_id-be.glean.com{authUrlRelativePath}. - When the user clicks Connect, redirect them (or open a popup) to that URL. They complete Glean's consent screen and then the provider's OAuth consent.
- After success, show a connected confirmation in your UI. Optionally call
checkdatasourceauthagain and confirm the instance no longer appears inunauthorizedDatasourceInstances.
Once a source is authorized, search, chat, and other Client API calls for that user will start including data from that source (for example, Slack RTS conversations), subject to permissions.
Reauthorization
For most connectors, OAuth is effectively "set it and forget it": Glean receives a long-lived refresh token and uses it to keep access tokens up to date automatically. Users only need to reauthorize if the provider revokes or expires the refresh token (for example, they revoke the app, their org rotates apps, or the provider enforces a new consent).
When that happens, Glean surfaces the source as needing authorization — in the connectors settings UI (Options 1 and 2) or via the checkdatasourceauth endpoint (Option 3) — so you can prompt users to reconnect.