Skip to main content

Action pack OAuth reference

This page covers two topics that apply across all action packs that use OAuth: choosing between central and custom OAuth, and understanding expected token lifetimes per provider.

For step-by-step setup instructions, see the setup page for the specific action pack you're configuring. For troubleshooting token refresh failures, see OAUTH_TOKEN_REFRESH_FAILED.

Central or custom OAuth

When you set up an action pack, most connectors offer two authentication options: central (Glean-managed) and custom (customer-managed). The right choice depends on your security model, operational preferences, and deployment type.

FactorCentral OAuthCustom OAuth
Setup effortLower — Glean manages the OAuth app registration and maintenanceHigher — you register, configure, and maintain the OAuth app in your identity provider
Token routingTokens are managed through Glean's central infrastructureTokens are managed through your deployment
Scope updatesAutomatic — when Glean adds new action capabilities, the central app's scopes are updated for youManual — you must add new scopes to your OAuth app and re-authorize
Consent screen brandingGlean-branded consent screenYour organization's branding
Conditional Access compatibilityShared app — may require allowlisting in your identity provider's policiesFull control — the app is registered in your tenant and subject to your own policies
Isolation from other customersShared infrastructureFully independent — your tokens and app are isolated
AvailabilityMost connectors (not all)All connectors that support OAuth

When to use central OAuth

Use central OAuth when:

  • You want the fastest path to a working action pack.
  • You're comfortable with Glean managing the OAuth app on your behalf.
  • Your identity provider doesn't have restrictive Conditional Access policies that block third-party apps.

When to use custom OAuth

Use custom OAuth when:

  • Your security team requires full ownership and control of the OAuth app.
  • Your identity provider's Conditional Access or tenant policies block shared third-party apps.
  • You need the consent screen to display your organization's branding instead of Glean's.
  • You want tokens to stay within your own deployment infrastructure.

Availability by connector

Not every connector offers both options. The table below summarizes what's available:

ConnectorCentral OAuthCustom OAuth
Microsoft 365YesYes
GoogleYesYes
Jira and Confluence (Atlassian)YesYes
SalesforceYesYes
ZendeskYesYes
SlackNoYes (custom only)

For setup instructions, see the connector-specific pages under Setup actions.

Expected token lifetimes

The table below lists the default token lifetimes for each provider. Organization-level policies — such as Conditional Access in Microsoft Entra or session controls in Google Workspace — can shorten these defaults.

ProviderAccess token lifetimeRefresh token lifetimeNotes
Microsoft Entra (Microsoft 365)~1 hour90 days (default)Conditional Access policies (sign-in frequency, device compliance, location restrictions) can shorten the refresh token lifetime or require re-authentication sooner. Review session controls under Entra ID → Security → Conditional Access.
Google~1 hourUntil revoked (default)Expires after 6 months of inactivity. Apps in Testing mode issue refresh tokens that expire after 7 days — set the consent screen to Internal or Production.
Atlassian (Jira, Confluence)~1 hour~90 days (rotating)Atlassian uses rotating refresh tokens — each refresh returns a new refresh token, so the 90-day window resets with each use.
Salesforce~1 hourUntil revoked (default)Admins can configure refresh token policies in Salesforce Setup. Connected app policies may override the default.
SlackDoesn't expireDoesn't expire (default)Tokens persist unless the app is uninstalled or token rotation is enabled in the Slack app configuration.
Zendesk~2 hoursUntil revokedTokens persist unless the OAuth client is deleted or the user's access is removed.

What happens when a token expires

When a refresh token expires or is revoked, Glean detects the failure during its next background refresh cycle and removes the stored token. The teammate sees a Connect prompt the next time they use the action. For re-authorization steps, see OAUTH_TOKEN_REFRESH_FAILED.

See also