Slack Single Sign-On: 8 Settings I Use to Secure Team Workflows

Last quarter I helped a fintech client offboard a contractor on a Friday afternoon. HR pulled access from email and the VPN by 4 p. m. On Monday morning the contractor was still posting in three private Slack channels. Nobody had remembered Slack was its own island.

That single gap is why I now refuse to set up a new Slack workspace without single sign-on wired in from day one.

Here’s the thing. Slack is where my marketing campaigns get briefed, where launch dates get approved, where draft copy gets pasted, where API keys sometimes get pasted (yes, I know). Treating it like a chat app instead of a system of record is how teams leak data without realizing it.

In this guide I’ll walk through what single sign-on in Slack actually is, why it matters for the way my team works, which plan you need, and the eight specific settings I turn on inside the admin panel within the first hour. I’ll also show you where SSO falls short, because it’s not magic.

What is single sign-on in Slack?

Single sign-on in Slack is a login method that lets your team access Slack through your company’s identity provider (IdP), like Okta or Microsoft Entra, instead of a separate Slack password. One login, one account, one place to revoke access.

Under the hood, Slack uses the open SAML 2.0 standard to exchange a signed authentication assertion with your IdP. When someone clicks “Sign in with SSO” on your Slack workspace URL, Slack redirects them to your IdP, the IdP confirms they’re a real employee, and Slack lets them in.

The practical upshot for me as a marketer running campaigns: the same person who can’t log into HubSpot anymore also can’t log into the #campaign-launches channel anymore. Access lives in one directory.

Look, this matters more than it sounds. Slack messages stick around. Pinned posts, threads from two years ago, files shared during a launch. If access isn’t tied to the central directory, you end up with ghost members nobody knows how to remove.

Why SSO matters for team workflow security

I’ll start with the data and then get to the workflow argument.

The Verizon 2025 Data Breach Investigations Report found that 22% of all breaches in 2025 started with stolen credentials. For basic web application attacks, that number jumps to 88%. And 54% of ransomware victims had credentials leaking in infostealer logs before the attack hit.

Real talk: every Slack password your team picks is a potential entry on that list. SSO collapses thousands of passwords (Slack + GitHub + Notion + your CRM + your ad accounts) into one identity, governed centrally.

But the security story is only half of why I push for SSO. The other half is workflow integrity.

When marketing workflows live in Slack (campaign briefs, approval threads, paid media spend sign-offs), the audit trail is only as trustworthy as the access list. If a freelancer who left in March is still listed as a workspace member in May, your “who approved this $40K media buy?” question has no clean answer. SSO gives you a clean answer.

The honest limitation: SSO doesn’t make Slack content itself more secure. A logged-in user can still copy a paid-ads spreadsheet into a DM. SSO controls who can be inside, not what they do once they’re there. You still need data loss prevention and a clear policy.

Which Slack plan do I need for SSO?

SSO with a custom SAML identity provider requires the Slack Business+ plan or higher. The Free and Pro plans only offer Google sign-in as a basic SSO option, which is fine for small teams already on Google Workspace but won’t satisfy security review.

Here’s the side-by-side I share with finance whenever I’m asking for the upgrade:

Plan	Custom SAML SSO	SCIM Provisioning	Session Duration Control	Multi-Workspace SSO
Free	No	No	No	No
Pro	No (Google only)	No	No	No
Business+	Yes	Yes	Yes	No
Enterprise Grid	Yes	Yes	Yes	Yes

If you’re a small team using Slack Pro and Google Workspace, Google sign-in covers a lot of the workflow security argument. Once you cross 15–20 people or pick up your first compliance customer, Business+ becomes the realistic floor.

I won’t pretend the price jump is fun. Business+ is significantly more per seat than Pro. The way I justify it to founders: one missed offboarding incident costs more in legal and remediation than two years of the upgrade.

How Slack SSO works under the hood (SAML 2.0 plus SCIM)

Slack splits secure team access into two protocols, and you need both to do this right.

SAML 2.0 handles authentication

SAML 2.0 answers the question “is this person who they say they are?” Your IdP signs a response with an X.509 certificate. Slack verifies the signature, reads the user’s email from the assertion, and matches it to a workspace member. According to the official Slack SAML SSO documentation, Slack supports any SAML 2.0-compatible identity provider, and the response must be signed and delivered via HTTP POST binding.

The IdPs I see most often in marketing org charts: Okta, Microsoft Entra ID (formerly Azure AD), Google Workspace, JumpCloud, Ping Identity, OneLogin. All work. I personally lean Okta because the admin UI is the cleanest for non-engineers.

SCIM handles the lifecycle

SCIM (System for Cross-domain Identity Management) answers the question “should this person still exist?” When you fire someone in your HRIS, the IdP marks them inactive, and SCIM tells Slack to deactivate the account automatically. No ticket. No reminder. No Friday-afternoon contractor still posting on Monday.

Without SCIM, you still have to manually deactivate Slack users every time someone leaves. With SCIM, that step disappears. In a 50-person org with normal turnover, I’d estimate SCIM saves the IT lead 3–4 hours per month on its own.

Honest limitation: SCIM is one-way. It pushes user state from your IdP to Slack. If someone changes their profile photo inside Slack, that change doesn’t sync back to Okta. For 99% of teams that’s fine, but worth knowing if you have a strict “single source of truth for everything” policy.

How to set up Slack SSO with Okta (a real example)

I’ll walk through Okta because it’s the most common IdP I see, but the steps map almost one-to-one to Entra and Google Workspace.

Step 1: Confirm Slack plan

Go to your Slack workspace → Settings & administration → Workspace settings. Check that you’re on Business+ or Enterprise Grid. If you’re not, you can’t enable SAML SSO. This is where most setup attempts die quietly.

Step 2: Add Slack as an app in Okta

In the Okta admin console, search the integration catalog for “Slack.” Okta has a pre-built integration that handles 80% of the SAML configuration automatically. Click “Add Integration” and assign it to the people or groups who should have Slack access.

Step 3: Copy the IdP metadata into Slack

Okta gives you three values: the SAML 2.0 Endpoint URL, the Issuer URL, and the X.509 certificate. Paste those three values into Slack at Settings & administration → Authentication → Configure → SAML.

This is where Slack actually verifies the connection. If the certificate is malformed or you copied an extra newline, Slack tells you immediately. The first time I did this I spent 20 minutes hunting a stray space before I noticed it.

Step 4: Choose your enforcement level

Slack lets you pick how strict SSO is:

• Optional: Members can use SSO or their Slack password. I never use this. It defeats the purpose.
• Required: Members must use SSO. Slack passwords are disabled.
• Required, with one-time exception for guests: Same as Required but multi-channel guests (vendors, agencies) can still use a Slack password.

For a marketing team running campaigns with three outside agencies, that third option is usually the right call.

Step 5: Enable SCIM in Okta

Inside the Slack app in Okta, switch to the Provisioning tab and turn on “Enable API integration.” Slack will give you an OAuth token; paste it in. Now Okta can create, update, and deactivate Slack users automatically.

Test by deactivating yourself in Okta (briefly). Your Slack session should kill within minutes.

Step 6: Run a fire drill

Pick one team member and revoke their Okta access. Time how long until they’re logged out of Slack on web and desktop. If it’s under five minutes, you’re done. If it’s hours, your SCIM polling interval is too long. Fix that before you call this rolled out.

8 SSO and workflow security settings I configure on day one

These are the eight switches I flip every time I roll out Slack SSO for a team workspace. None of them are dramatic on their own. Together they close most of the obvious holes.

1. Set session duration to 7 days for members, 1 day for guests

Slack’s default session can run for 90 days. That’s too long for a marketing team that loses laptops in cabs. I cap members at 7 days (still convenient) and guests at 24 hours.

2. Require two-factor authentication at the IdP level

SSO without MFA at the IdP is a fancy single point of failure. Turn on TOTP or hardware key at Okta, not at Slack. That way every app inside SSO inherits MFA at once.

3. Lock workspace creation to admins only

Without this, anyone on your domain can spin up a new Slack workspace and bypass the SSO config on the parent one. I’ve seen this happen at three companies. Lock it down.

4. Enforce SCIM deprovisioning

Don’t just connect SCIM. Make it the only way someone leaves Slack. Disable the manual “remove member” flow for anyone but a primary owner. Forces the workflow back through HR.

5. Audit guest access monthly

SCIM doesn’t fully manage multi-channel guests in every plan tier. I run a manual report on the first Monday of every month, list every guest, and confirm with the channel owner that they still need access. Three or four get cut every time.

6. Restrict email domains for new accounts

In Slack admin settings, lock new account creation to your company’s email domains. Combined with SSO, this means a typo’d invite to a Gmail address can’t accidentally onboard a stranger.

7. Turn on session reset on credential change

When someone resets their IdP password, Slack should force a fresh login. It’s not on by default in older workspaces. Check it.

8. Enable audit logs export

On Enterprise Grid, push audit logs to a SIEM (we use Datadog). On Business+, at minimum review the in-app logs weekly. The first time someone tries to brute-force a guest account, you want to know within hours, not weeks.

How SSO ties into your link-sharing workflow

This is the piece almost nobody writes about. SSO doesn’t just protect login. It protects the integrity of every link your team shares inside Slack.

Here’s what I mean. Marketing teams paste hundreds of campaign links into Slack channels every week. Drafts, previews, paid-ad destinations, tracked Slack-shared URLs, tracking dashboards. When a former employee can still open those channels, they can still see those links, scrape your campaign structure, even click and inflate click tracking data.

The pattern I use:

1. SSO gates who can join the channel
2. Link protection at the URL level catches bot or fraudulent clicks if a link does leak
3. Naming rules (mine follow the same logic as UTM naming conventions) keep channel posts predictable so anomalies stand out
4. Automated link rules flag any campaign URL that violates the convention before it gets pasted

That’s the four-layer model. SSO is layer one. Without it, the other three protect a leaky bucket.

One related point: if your team shares short links in Slack, train them on how to tell if a link is safe. SSO won’t help if the campaign link itself is a phishing redirect a teammate accepted from a fake “agency partner” DM.

Real examples of teams that got SSO right (and one that didn’t)

Example 1: Vimeo (Okta + Slack, public case)

Vimeo publicly shared their use of Okta to centralize identity across SaaS apps, including Slack. According to Okta’s published customer story, the security team reduced onboarding time per new hire and standardized access reviews across hundreds of apps. The takeaway: SSO scales precisely because every new app you adopt inherits the central directory automatically.
Source: Okta customer stories, okta.com/customers/vimeo

Example 2: Slack’s own offboarding workflow at Atlassian (public talk)

At Atlassian’s Team summit, an IT leader described moving from manual Slack offboarding to SCIM-based automation. The metric they shared publicly: deprovisioning latency dropped from “hours to days” down to “under 15 minutes” for the median departure.
Source: Atlassian Team conference public sessions (atlassian.com/team)

Example 3: A health-tech startup I helped (anonymized)

A 35-person health-tech startup I consulted with last year had no SSO. They were chasing SOC 2 and assumed Slack security wasn’t in scope. Their auditor disagreed and flagged “no centralized authentication for collaboration tools” as a finding. We connected Slack to their existing Okta tenant in an afternoon. The finding cleared. The actual unlocked value: their CISO finally had one screen to revoke access from when someone left.

What single sign-on in Slack does not solve

I want to be honest about this section because the SSO marketing usually overpromises.

• It does not stop insider data exfiltration. A logged-in member can still copy paid-search data into a personal Notion. You need DLP for that.
• It does not encrypt message contents end-to-end. Slack messages are encrypted in transit and at rest, but Slack admins (and Slack the company) can technically see them. Enterprise Key Management is a separate paid add-on.
• It does not stop phishing through Slack itself. Attackers send malicious links inside Slack as often as they do over email now. SSO logs the click. It doesn’t block it.
• It does not magically clean up your existing user list. When you turn on SSO, you still need to reconcile current members against your IdP. I’ve seen workspaces with 200 active accounts and only 140 matching IdP users. That’s 60 ghosts.
• It does not work on Free or Pro plans with custom SAML. If your team is below 30 people on Slack Pro, you’re stuck with Google sign-in until you upgrade.

None of these are reasons to skip SSO. They’re reasons to plan for the next thing after SSO.

Single sign-on in Slack: frequently asked questions

Does Slack support single sign-on?

Yes. Slack supports SAML 2.0 single sign-on through any SAML-compatible identity provider, including Okta, Microsoft Entra ID, Google Workspace, JumpCloud, OneLogin, and Ping Identity. It’s available on the Business+ and Enterprise Grid plans.

Which Slack plan do I need for SSO?

Custom SAML SSO requires Slack Business+ or Enterprise Grid. The Free and Pro plans only offer Google sign-in, which is a limited form of SSO but doesn’t support arbitrary identity providers or SCIM provisioning.

Is Slack SAML SSO secure on its own?

SSO is secure for authentication, but it’s not a complete security setup by itself. You should also enable multi-factor authentication at the identity provider level, configure session duration limits in Slack, and connect SCIM so user deprovisioning is automatic.

What’s the difference between SSO and SCIM in Slack?

SSO (using SAML 2.0) handles the login itself: it verifies who someone is at the moment they sign in. SCIM handles the user lifecycle: it creates, updates, and deactivates user accounts automatically based on what your identity provider says. You generally want both turned on.

Can I force every member to log in through SSO?

Yes. In Slack admin settings under Authentication, set SSO to “Required.” This disables Slack password login for all members. You can choose to exempt multi-channel guests if you work with outside agencies who don’t sit in your IdP.

What happens when I deactivate a user in my identity provider?

If SCIM is enabled, Slack receives the deactivation event and ends the user’s Slack session within minutes. Their account is set to inactive, their messages stay (for audit purposes), and they can no longer log in.

How long does Slack SSO setup take?

For a workspace already on Business+ with an existing IdP, the SAML side takes 30–60 minutes. Adding SCIM takes another 30 minutes. The longer task is auditing your current member list against your IdP, which can take a few hours for workspaces over 100 people.

Can free Slack workspaces use SSO?

Free Slack workspaces can use Google sign-in, but they can’t use custom SAML SSO with providers like Okta or Entra ID, and they can’t enable SCIM. For real SSO, you need Business+ or higher.

Start with one setting today

If you skim past everything above and only do one thing this week, do this: confirm that Slack deactivation is part of your offboarding checklist, even if you haven’t enabled SSO yet. Most of the damage from a missed Slack offboarding happens in the first 72 hours after a departure.

Then, when you’re ready to wire SSO in properly, work the eight-setting list above in order. Session limits and required SSO are the two with the biggest immediate impact.

Looking to keep your campaign link workflow as tight as your Slack access? Check out linkutm’s team features for shared workspaces, link protection, and naming rules that work the same way SSO does: governance enforced once, applied everywhere.