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.
Provider guidance
Google Workspace
Google Workspace authorization uses domain-wide delegation. A Super Admin must copy the client ID and exact scopes displayed by Elba into Google Admin Console. See Connect Google Workspace.
Microsoft 365
Microsoft shows the requested organization-wide permissions during tenant consent. Use a Global Administrator for the complete flow. See Connect Microsoft 365.
Okta
The Okta service integration uses these read scopes:
okta.apps.read
okta.users.read
okta.roles.read
okta.groups.readThe SSO application requests okta.users.read.self for the signed-in administrator. See Connect Okta.
Slack
Slack lists the requested app permissions during installation. Your workspace’s app-management policy determines who can approve them. See Connect Slack.
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.