User Data Source 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 data sources (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 data sources page

Users with access to the Glean web app Admin console can authorize per-user sources directly in the Glean UI. In Admin Console → Data sources, users can see which sources need authentication and which are already connected.

What users do

Users can do the following to authorize per-user sources:

1. Sign in to Glean in the browser (via SSO or other configured auth).
2. Open Admin Console → Data sources.
3. Find sources such as Slack (RTS) or GitHub and click Connect or Authorize.
4. Complete the OAuth consent flow with for the selected data source 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

warning

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 the Glean Web SDK, or you want users to stay entirely inside your app, you can render a data sources component similar to Glean's own page. That component lists per-user sources and you can embed Connect and Authorize actions 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

1. Initialize the Web SDK using your existing authenticaiton mechanism so Glean can identify the current user.
2. Mount the data sources component on your Search settings or Connect apps page. It lists per-user data sources that need auth for the active user and shows Connect and Authorize actions for each.
3. 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.
4. 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 data source instances require per-user OAuth, then build your own UI around that.

tip

See the datasources-demo-app for a working example that uses this API to render a page where users can authorize their data sources.

Endpoint

Field	Value
Method	POST
Path	/rest/api/v1/checkdatasourceauth
Base URL	https://{instance}-be.glean.com
Auth	Bearer Client API token for the authenticated user or service

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_INSTANCE is your tenant instance ID (e.g. acme).
• GLEAN_API_TOKEN is a Client API token that authorizes calls on behalf of the user.

Build your own "Connect apps" UI

A typical headless flow:

1. Call checkdatasourceauth as the current user.
2. For each item in unauthorizedDatasourceInstances, render actions such as Connect Slack or Connect GitHub, and build the full OAuth URL as https://{instance}-be.glean.com{authUrlRelativePath}.
3. 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.
4. After success, show a connected confirmation in your UI. Optionally call checkdatasourceauth again and confirm the instance no longer appears in unauthorizedDatasourceInstances.

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 data sources, 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 data sources settings UI (Options 1 and 2) or via the checkdatasourceauth endpoint (Option 3) — so you can prompt users to reconnect.

See also

• OAuth overview
• Glean OAuth Authorization Server