Skip to main content

OAuth options for action packs

Use this page to choose between central OAuth and custom OAuth for OAuth-based action packs. This guide explains when to use each option, which connectors support them, and what token lifetimes to expect after setup.

After you choose your OAuth model, continue to the setup page for your connector under Set up actions.

note

Not all OAuth-based action packs support both options. For example, Slack supports custom OAuth only.

Choosing the right OAuth model

OAuth-based tools support one or both of these options:

FactorCentral OAuthCustom OAuth
Setup effortLower. Glean manages the OAuth application and ongoing maintenance.Higher. Your organization registers, configures, and maintains the OAuth application.
Token managementTokens are managed through Glean's central OAuth infrastructure.Tokens are managed through your deployment configuration.
Scope changesWhen Glean adds capabilities, the central OAuth application is updated for you.Your team must add scopes and reauthorize users when capabilities change.
Consent screenShows Glean branding.Shows your organization's branding.
Conditional Access compatibilityMay require allowlisting the Glean application in your identity provider.Uses an application in your tenant and follows your internal policies.
IsolationUses shared infrastructure.Isolated to your tenant and application.
Best fitBest if you want the fastest path to setup and are comfortable with Glean managing the OAuth application.Best if your security or compliance team requires ownership of the OAuth application, or if your tenant policies block shared third-party applications.

For example, choose custom OAuth if your Microsoft Entra policies require a tenant-owned app registration or block shared third-party apps. Choose central OAuth if you want a faster setup for connectors such as Google, Salesforce, or Atlassian and your security policies allow a Glean-managed app.

OAuth model availability by connector

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

Expected token lifetimes

When planning your deployment, it is important to understand how long user connections remain valid. Regardless of whether you choose central OAuth or custom OAuth, access and refresh tokens inherit the default lifetimes enforced by each identity provider.

The values below represent provider defaults. Your organization's identity, session, or Conditional Access policies can shorten these durations and require users to reauthenticate sooner.

ProviderAccess token lifetimeRefresh token lifetimeNotes
Microsoft Entra (Microsoft 365)~1 hour90 days by defaultConditional Access policies such as sign-in frequency, device compliance, or location restrictions can shorten these lifetimes. Review session controls in Entra ID > Security > Conditional Access.
Google~1 hourUntil revoked by defaultRefresh tokens expire 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 for long-lived access.
Atlassian (Jira, Confluence)~1 hour~90 days, rotatingAtlassian uses rotating refresh tokens. Each successful refresh returns a new refresh token, which resets the 90-day inactivity window.
Salesforce~1 hourUntil revoked by defaultAdmins can configure refresh token policies in Salesforce Setup. Connected app policies can override the default.
SlackDoes not expire by defaultDoes not expire by defaultTokens remain valid unless the app is uninstalled or token rotation is enabled in the Slack app configuration.
Zendesk~2 hoursUntil revokedTokens remain valid unless the OAuth client is deleted or the user's access is removed.

What happens when a token expires

If an access token expires, Glean uses the stored refresh token to get a new one automatically.

If the refresh token has expired or been revoked, the next refresh attempt fails and the saved connection becomes invalid.

See also