OAuth scopes and permissions

Understand how Elba requests integration permissions and where to verify the current scope set.

Elba requests permissions according to the connector and capabilities being enabled. The exact set can vary by provider, region, and product configuration.

Use the authorization screen as the source of truth

Review the permissions shown by Elba and the provider during connection. Do not approve a scope list copied from an old screenshot or knowledge-base article.

Why permissions differ

Directory read permissions import users, groups, and account metadata.
Security and audit read permissions collect the signals used to surface supported findings.
Content or sharing permissions support data-protection analysis for the selected provider.
Write permissions are requested only where a connector supports a remediation action, such as changing access or revoking a supported grant.
Offline access lets Elba refresh an authorized connection without asking an administrator to sign in for every synchronization.

Not every connector supports every capability or automated action. See integration capabilities and check the live integration catalog in your workspace.

Google uses separate authorization grants for sign-in, directory synchronization, security analysis, and optional capabilities. A Super Admin must copy the client ID and exact domain-wide delegation scopes displayed by Elba into Google Admin Console. See Connect Google Workspace.

openid (OpenID Connect): Authenticate the signed-in Google user and receive an identity token.
profile (OpenID Connect): Read the signed-in user's basic profile claims.
email (OpenID Connect): Read the signed-in user's email claim.
https://www.googleapis.com/auth/admin.directory.user.readonly (delegated): Validate the signed-in user's Workspace account and administrator role during setup.

Directory synchronization

These scopes use domain-wide delegation:

https://www.googleapis.com/auth/admin.directory.domain.readonly: Read the Workspace domains used to identify the organization.
https://www.googleapis.com/auth/admin.directory.group.readonly: Read groups and group membership for synchronization.
https://www.googleapis.com/auth/admin.directory.user.readonly: Read user profiles for provisioning and reconciliation.

Security and Data Protection

The Google security-source connection uses a separate domain-wide delegation grant:

https://www.googleapis.com/auth/admin.directory.group.member.readonly: Resolve owners of Google groups referenced by shared-drive permissions.
https://www.googleapis.com/auth/admin.directory.user.readonly: Map Google users to Elba members and resource owners.
https://www.googleapis.com/auth/admin.directory.user.security: Read and revoke supported user OAuth grants for Third-Party Apps findings.
https://www.googleapis.com/auth/drive: List Drive files, read selected metadata and sharing permissions, and apply supported permission-removal actions.

The drive scope grants broad access to Drive data available to the impersonated account. Elba uses it for the enabled security and Data Protection workflows; review the live delegation entry before approval.

Optional Google capabilities

Phishing simulations, https://www.googleapis.com/auth/gmail.insert: Insert simulation messages into inboxes without sending mail.
Google Chat, https://www.googleapis.com/auth/admin.directory.user.readonly: Resolve eligible users for the Chat integration.
Google Chat, https://www.googleapis.com/auth/chat.spaces.create: Create supported Chat spaces for employee communications.

Microsoft 365

Microsoft shows the requested organization-wide permissions during tenant consent. Use a Global Administrator for the complete flow. See Connect Microsoft 365.

Elba uses delegated permissions during Microsoft sign-in and application permissions for processing without a signed-in user. The permissions are split across Microsoft consent flows, so they are not all requested at the same time.

Permission	Type	Why Elba requests it
`openid`	OpenID Connect	Authenticate the signed-in Microsoft user and receive an identity token.
`profile`	OpenID Connect	Read the signed-in Microsoft user's basic profile claims.
`email`	OpenID Connect	Read the signed-in Microsoft user's email claim.
`offline_access`	OpenID Connect	Allow Microsoft to issue a refresh token for delegated access.
`User.Read`	Delegated	Read the signed-in Microsoft user's ID, name, and email.
`Directory.Read.All`	Delegated	Read tenant, directory, and role information needed to validate the organization and administrator.
`User.Read.All`	Application	Read user profiles to provision and reconcile eligible Elba members.
`Directory.Read.All`	Application	Read users, groups, memberships, and directory metadata for synchronization and selected-group validation.

Optional Microsoft capabilities

These are application permissions used by separate optional capabilities:

Phishing simulations, Mail.ReadWrite: Elba uses it to create simulation messages directly in user inboxes. By default, the application permission allows creating, reading, updating, and deleting mail in all tenant mailboxes; it does not include Mail.Send.
Teams notifications, AppCatalog.Read.All: Find the Elba application in the tenant's Microsoft Teams app catalog.
Teams notifications, TeamsAppInstallation.ReadWriteSelfForUser.All: Elba uses it to install its Teams application for users. The permission can also update or remove that same application.
Teams notifications, User.Read.All: Resolve eligible Microsoft users for application installation and notifications.

Phishing simulations and Teams notifications use separate Elba Microsoft applications and consent flows. The Microsoft consent screen is authoritative for each flow; if it displays a permission that is not listed here, contact Elba before approving it. Microsoft's Graph permissions reference describes the maximum access granted by each permission.

During onboarding, you can limit the Microsoft directory records Elba imports to one Entra security group. This is a query-and-storage boundary, not a Microsoft authorization boundary: the application permissions shown during tenant consent remain tenant-wide. In group mode, Elba queries and stores only the selected group's metadata and its eligible direct members during directory synchronization.

Okta

The Okta service integration and SSO application use separate grants:

Scope	Grant	Why Elba requests it
`okta.apps.read`	Service integration	Read assigned applications and application assignments.
`okta.users.read`	Service integration	Read users and their status for synchronization.
`okta.roles.read`	Service integration	Read administrative roles used by security findings.
`okta.groups.read`	Service integration	Read groups and group membership.
`okta.users.read.self`	SSO	Read the profile of the user signing in to Elba.

See Connect Okta.

Slack

Elba uses separate Slack applications for employee communications and Data Protection. They do not request the same permissions.

Employee communications

Bot scope	Why Elba requests it
`users:read`	Match active Slack members to Elba members.
`users:read.email`	Match members by email address.
`chat:write`	Send supported Elba messages.
`im:write`	Open direct-message conversations with matched members.
`chat:write.customize`	Present supported messages using Elba's configured identity.

Data Protection

User scope	Why Elba requests it
`channels:history`	Analyze supported messages in public channels available to the authorized connection.
`channels:read`	Read public-channel metadata.
`chat:write`	Apply supported message remediation through Slack where permitted.
`team:read`	Read workspace metadata.
`users:read`	Resolve message authors and Slack members.
`users:read.email`	Match Slack members to Elba members by email address.

These Data Protection permissions do not grant access to private-channel history. Slack lists the requested app permissions during installation, and your workspace's app-management policy determines who can approve them. See Connect Slack.

Confluence

The Confluence Data Protection connection currently requests these OAuth 2.0 scopes:

Scope	Why Elba requests it
`offline_access`	Refresh the connection without repeated administrator sign-in.
`read:confluence-user`	Validate the authorizing Confluence user.
`read:group:confluence`	Read Confluence groups.
`read:user:confluence`	Read users and group membership.
`read:content-details:confluence`	Read content and restriction details used by findings.
`write:content.restriction:confluence`	Remove supported page restrictions during remediation.
`read:page:confluence`	Read page metadata.
`read:permission:confluence`	Read space permissions.
`write:space.permission:confluence`	Remove supported space permissions during remediation.
`read:space:confluence`	Read Confluence space metadata.

Confluence permissions remain subject to the authorizing user's own access. Atlassian's Confluence scope reference describes the maximum access granted by each scope.

Dropbox

The current Dropbox Business connector calls routes that require these scopes:

Scope	Why Elba requests it
`team_info.read`	Validate the connected team and authorizing team administrator.
`account_info.read`	Read the authenticated administrator's account and team namespace.
`members.read`	Synchronize team members.
`members.write`	Suspend a supported team member during remediation.
`sessions.list`	List linked applications for Third-Party Apps findings.
`sessions.modify`	Revoke a supported linked application.
`files.metadata.read`	Read file and folder metadata without downloading file content.
`sharing.read`	Read sharing members and shared-link metadata.
`sharing.write`	Remove supported sharing members and revoke shared links.
`team_data.member`	Act on member namespaces when reading metadata or remediating sharing.

Dropbox app permissions are configured in the Dropbox App Console, so the Dropbox authorization screen is the exhaustive source for the enabled grant. The Dropbox SDK route reference identifies the scope required by each API route.

SharePoint and OneDrive

SharePoint and OneDrive Data Protection use a separate Microsoft application with application permissions and the client-credentials .default grant. The connector reads users, sites, drives, items, and permissions, creates change subscriptions, and removes supported item permissions.

Unlike an explicit OAuth scope string, .default requests the application roles configured on Elba's live Entra application registration. Those roles are therefore shown exhaustively on Microsoft's tenant-consent screen rather than embedded in the connector. Review that screen before approval and contact Elba if it contains a permission you do not expect. In particular, Sites.FullControl.All, when displayed, allows full control of all site collections; it is not a read-only permission.

Security review

For a connector-specific permission review, contact [email protected] and include the provider, workspace region, and capability you intend to enable. Never include client secrets or API keys.