What does my Microsoft 365 admin need to approve to enable SlackBridge?

TL;DR. Microsoft Teams uses application-level Graph API permissions, which can only be granted by a Microsoft 365 Global Administrator (or Cloud Application Administrator). SlackBridge generates a single sign-in link that takes the admin to Microsoft's standard consent screen at login.microsoftonline.com — the screen lists every permission SlackBridge will receive. Admin clicks Accept once, the consent is recorded against the tenant, and SlackBridge can then bridge messages. The consent link is valid for seven days. SlackBridge never sees the admin's password and never gets delegated user permissions; consent is granted to the SlackBridge application as a whole.

What's the short version?

To enable SlackBridge in a Microsoft 365 tenant, a Microsoft administrator clicks a link, sees Microsoft's standard consent screen, and clicks Accept. The whole flow happens on Microsoft's own login page (login.microsoftonline.com); SlackBridge never sees the admin's password. The decision is made once, by the admin, on behalf of the tenant.

This article walks through what the admin will see, why each step is necessary, and how the tenant retains full control.

Who can grant consent?

Microsoft requires an Entra ID role that includes the "Grant tenant-wide admin consent" permission. The eligible roles are:

• Global Administrator (most common)
• Privileged Role Administrator
• Cloud Application Administrator

A regular user — even one who is the owner of every Microsoft Teams team in the tenant — cannot grant the consent SlackBridge needs. This is a Microsoft restriction, not a SlackBridge one. The reason is that SlackBridge requests application permissions (which act on behalf of the application itself, not on behalf of any user), and only a tenant administrator can authorize an application to act tenant-wide.

If the admin link is opened by a non-administrator, Microsoft will display an error explaining that admin consent is required.

What the admin sees

When the admin clicks the consent link, the browser is sent to a URL of this shape on Microsoft's domain:

https://login.microsoftonline.com/{tenant-or-common}/adminconsent
  ?client_id={SlackBridge-application-ID}
  &redirect_uri={SlackBridge-callback-URL}
  &state={CSRF-protected-token}
  &scope=https%3A%2F%2Fgraph.microsoft.com%2F.default
  &prompt=select_account

After the account picker, Microsoft displays the standard tenant-consent screen, which lists every Microsoft Graph permission the SlackBridge application has declared (six for Core Bridging, ten for Full Integration), the publisher name (Square Post Labs Inc.), the publisher's verified-publisher status, and Accept / Cancel buttons.

The screen is rendered entirely by Microsoft. SlackBridge never sees the admin's password and cannot influence which permissions Microsoft displays beyond the ones already declared on the application registration.

For the exhaustive list of permissions in each tier and what each one is used for, see the permissions article.

Why application permissions, not delegated permissions?

Microsoft Graph offers two permission models:

SlackBridge bridges messages when no human is signed in (overnight, on weekends, immediately after a Teams user posts). It needs to act on its own identity rather than impersonate a user. That requires application permissions, which by Microsoft's design require admin consent.

The corollary is that SlackBridge cannot silently expand its access. Every permission it has was approved by a tenant administrator and is visible in Enterprise Applications.

What gets recorded after consent

When the admin clicks Accept, three things happen on Microsoft's side:

1. The SlackBridge application is registered in the tenant's Enterprise Applications list.
2. A service-principal record is created with the granted application permissions.
3. An admin-consent audit event is written to the Microsoft 365 audit log.

On the SlackBridge side:

1. The CSRF state token is validated and consumed.
2. SlackBridge requests an access token from Microsoft using the now-granted application permissions.
3. The access token is encrypted and stored; the refresh token is similarly encrypted and stored.
4. A SlackBridge audit-chain event is written recording the consent grant, the tenant ID, and the tier (Core Bridging or Full Integration).

From here on, SlackBridge can subscribe to Microsoft Graph change notifications for the channels you map and bridge messages in both directions.

Revoking consent

The admin retains full control. Consent can be revoked at any time:

1. Sign in to Microsoft 365 admin center as Global Administrator.
2. Open Entra ID → Enterprise Applications.
3. Search for "SlackBridge" (or "SlackBridge Advanced" for the Full Integration tier).
4. Open Properties → Delete.

Revocation is instant. SlackBridge's stored tokens for that tenant become invalid the moment Microsoft purges the application's service principal, and any in-flight Microsoft Graph requests fail with HTTP 401. As a clean-up step, also remove the connection from the SlackBridge dashboard so the SlackBridge side stops attempting to refresh tokens.

Common questions admins ask before clicking Accept

These come up in security reviews. The full list of permissions, with rationale per permission, lives in the permissions article. The data-handling specifics — what is and is not stored, retention windows, encryption — live in the data retention article. For the security review summary:

• SlackBridge does not request Mail, Calendar, Files, Sites, OneDrive, OneNote, or Tasks permissions on Microsoft Graph.
• SlackBridge does not request the ability to send messages on behalf of any individual Teams user.
• SlackBridge does not request the ability to read direct (1:1 or group) chat messages — only channel messages, and only in the channels you explicitly map.
• SlackBridge stores no message body text, only short-lived ID metadata used to keep replies threaded. See the retention article for exact windows.