How authentik and Slack SAML SSO works and when SCIM is worth adding
SAML single sign-on is the core method for signing people in to Slack through authentik, and SCIM provisioning is an optional addition you add only if you want user accounts created and removed automatically. The authentik Slack integration guide describes this supported path, and it should be your starting reference for the exact provider settings. Slack's side needs a plan with custom SAML and a Workspace or Org Owner who can configure it, so confirm that account exists before any build work starts. The work splits cleanly between the two systems. In authentik, you create a SAML provider and application, define the attributes Slack expects (typically the email address and name fields) through property mappings, and control who can reach the application through group membership and policy bindings. In Slack, the owner configures the SAML connection, sets the sign-in URL and certificate from authentik, and decides how members are routed into the workspace. Each change on one side has to match the other, so keep a short record of the values you copied across, including the entity ID and the ACS URL, and test with a non-owner account before you enforce SSO for everyone.
Decide on SCIM only after SAML login works reliably. SCIM needs a Slack plan of Business+ or Enterprise and an app with the admin OAuth scope, so the plan decision drives whether you can automate provisioning at all. Without SCIM, accounts are created at first sign-in and remain active until an administrator removes them, which means leavers keep access unless someone acts. With SCIM, deprovisioning follows what authentik does to the user, so the important check is that removing a person from the authentik group or deactivating the account actually reaches Slack. Confirm that flow in a test workspace, and agree with HR or your identity owner who triggers offboarding, because that step, not the protocol, decides how quickly a leaver loses access.
What you need before configuring Slack with authentik
Five checks settle whether the Slack integration can start and what it will cost to run. Slack plan tier controls both SAML and SCIM, the account used for setup controls who can make the change, and the authentik release and endpoint set the foundation the rest depends on.
Slack plan for custom SAML
Custom SAML sign-in requires a Slack plan that includes it, and the authentik Slack guide says the setup must be done by a Workspace or Org Owner. Confirm the plan tier on your own workspace before scheduling work, because the option is not available on every tier. Ask the Slack account team to confirm the current tier if your contract is on a legacy plan.
Owner account for setup
The person making the change must hold the Workspace or Org Owner role in Slack, so the team should name that account and its backup before the work starts. Plan for an MFA-protected owner account that is not a shared login. Record who holds ownership, because removing or demoting the only owner can block later changes to SSO settings.
SCIM tier and admin OAuth scope
Optional SCIM provisioning needs Slack Business+ or Enterprise, plus an app in Slack that holds the admin OAuth scope. Without that scope, authentik cannot create, update or deactivate accounts in Slack. Confirm the tier and scope together, since a SAML-only plan will not carry the provisioning step.
Confirm the authentik release
Check that your authentik version appears on the supported list in the security policy before you configure anything. The supported versions named there are 2026.5.x and 2026.8.x, and the project announces security releases at least 24 hours ahead. Plan the upgrade path first if your current release is outside that list.
Reachable HTTPS endpoint
Slack must reach authentik over HTTPS with a certificate that a browser and Slack both trust, so the authentik hostname needs DNS and a valid certificate chain. Confirm the hostname is reachable from the internet, not only from an internal network, and that the reverse proxy passes the SAML callback paths. Test the endpoint from outside your network before starting the Slack setup.
Retention and export implications
The Slack plan also sets how long history stays available. Free workspaces keep 90 days of message and file history, and content older than one year is permanently deleted, while paid plans carry unlimited message history. Exporting private channels and direct messages requires Business+ or Enterprise, so the plan choice affects what you can retrieve later, not only sign-in.
Configuration sequence from authentik SAML provider to first Slack login
This sequence connects a self-hosted authentik SAML provider to Slack in an order that limits lockout risk: prerequisites first, then a single-user test, then the whole workspace, with SCIM added last. Each step closes with a check you can run before moving on.
Confirm the Slack plan and owner account
Before changing either system, confirm that your Slack plan includes custom SAML and identify the Workspace or Org Owner who will make the change. The authentik Slack guide sets out the plan and role requirements, so check them against your current Slack subscription before you start. Record the owner's sign-in method and confirm that its password and MFA work, since this account is the path back in if SAML fails. Done when the plan, the owner and a tested break-glass sign-in are written down.
Create the SAML provider and application
In the authentik admin interface, create a SAML provider for Slack and an application that uses it, then bind the provider to the groups or users who should sign in to the workspace. Set the endpoint, audience and name ID values as the authentik Slack guide specifies for your workspace, and note the issuer and signing certificate for later. Confirm that a test account sees the Slack tile in its authentik library. Done when the provider saves without errors and the test account can launch the application.
Export metadata and configure Slack SAML
Export the SAML metadata or copy the sign-in URL, entity ID and certificate from the authentik provider page, then enter them in Slack's SAML settings while signed in as the owner. Copy values directly from authentik to avoid typing errors in the certificate or URLs. Keep SSO enforcement off for the whole workspace at this stage, and confirm with the authentik Slack guide how Slack handles testing before enforcement. Done when the Slack SAML configuration saves and the owner sees the populated settings page.
Test a single user sign-in
Sign in to Slack with a pilot account through the authentik login flow, starting from a clean browser session. Check that the account reaches the correct workspace, that the name and email match the existing Slack profile, and that the user can open the channels they need. Repeat the test with a second pilot account from a different authentik group if your group model has more than one tier. Done when both pilot sign-ins complete without manual intervention and the profile data matches what you expect.
Enable SSO for the workspace
Once the pilot passes, enable SAML for the workspace and tell members which sign-in path to use, with a cutover date agreed by your team. Keep the owner account outside SSO enforcement so an administrator can still recover access if the provider certificate or metadata changes. Record the certificate expiry in your team's calendar so that renewal is planned rather than urgent. Done when a member who was not part of the pilot signs in through authentik and the owner's break-glass sign-in still works.
Add SCIM after SAML is stable
Add SCIM provisioning only after SAML sign-in works for members. The authentik Slack guide says SCIM needs Slack Business+ or Enterprise and an app with the admin OAuth scope, so confirm your plan before creating the app. Create the SCIM application in authentik, enter the Slack SCIM endpoint and token, and map the attributes the guide lists. Done when a test user created in authentik appears in Slack as a provisioned member.
Verify deprovisioning with a test leaver
Disable a test user in authentik and confirm that the change reaches Slack through SCIM. Check that the Slack account is deactivated and that existing sessions end or fail on the next sign-in attempt. Compare the result with your offboarding procedure, including who takes ownership of the content and files the departing user created. Done when the test leaver shows as deactivated in Slack and the verified steps are recorded in your runbook.
Which Slack plan fits SAML only versus SAML with SCIM
SAML sign-in lets users authenticate to Slack through authentik, but accounts are still created and removed inside Slack. This option requires a Slack plan that allows custom SAML, and the setup must be completed by a Workspace or Org Owner. Users who sign in for the first time are matched by email, and any account you disable in authentik still exists in Slack until someone removes it there manually.
- Plan gate: Confirm on Slack's pricing page that your target plan includes custom SAML, because the feature set differs between tiers.
- Owner dependency: The Workspace or Org Owner who configures SAML must be available for setup and for later certificate or endpoint changes.
- Account lifecycle: Without SCIM, leavers keep active Slack accounts until an administrator deactivates them, so document a manual offboarding step.
- History limits: The Free plan keeps 90 days of message and file history, and Slack states that content on Free workspaces older than one year is permanently deleted. The Pro plan offers unlimited message history, which matters if you need older conversations retained.
- Export rights: Every plan can export messages and file links from public channels. Private channels and direct messages require Business+ or Enterprise.
Before you commit to this option, confirm the current plan features on Slack's pricing page and check how your retention and export needs map to each tier.
SAML with SCIM adds automated user creation, attribute updates and deactivation driven from authentik. The authentik Slack guide lists optional SCIM provisioning as requiring Slack Business+ or Enterprise, and it requires an app with the admin OAuth scope. This is the option to choose when leaver removal must happen from the identity provider rather than from a manual Slack task.
- Plan gate: SCIM provisioning requires Business+ or Enterprise, which is a higher tier than the SAML-only option.
- Admin scope: The Slack app used for provisioning must carry the admin OAuth scope, so plan who approves and holds that app.
- Deprovisioning: When a user is deactivated or removed in authentik, the SCIM connection is the mechanism that carries that change to Slack. Test this with a non-production user before relying on it.
- Export rights: Business+ and Enterprise allow exports of private channels and direct messages, which may be relevant to your records obligations.
- Data residency: Data residency is available on Business+ or Enterprise, which may influence the tier you pick if regional storage is required.
Confirm the SCIM and admin scope requirements with the authentik Slack guide and current Slack plan details before you approve the purchase.
Plan choice affects more than login. Retention, exports and compliance tooling vary by tier, so a plan that suits sign-in alone may not meet your records or investigation needs. Map each requirement to a tier before you configure anything, because changing plans later can change what history and exports you can access.
- Free plan retention: Message and file history is limited to 90 days, and older Free workspace content is permanently deleted after one year, so Free is unsuitable where history must be kept.
- Pro plan history: Pro includes unlimited message history but does not provide the private channel and direct message export rights that Business+ and Enterprise offer.
- Key management: Enterprise Key Management is an add-on on Business+ and included on Enterprise+, which matters if you hold encryption keys under your own policy.
- Export scope: Custom exports by member or conversation are Enterprise-only, which affects investigations of specific users.
- Cost components: Your licence fees are paid to Slack, while the authentik configuration and SCIM work is a separate engagement whose scope you agree in writing.
Ask Slack to confirm which retention, export and key management features apply to your plan and region before you sign.
The right option depends on how quickly leavers must lose access and whether you can accept manual account cleanup. SAML sign-in alone centralizes authentication but leaves account lifecycle in Slack. SAML with SCIM moves lifecycle into authentik, which fits organizations that treat the identity provider as the system of record. The decision is mostly about operational discipline and plan cost rather than technical difficulty.
- Choose SAML only when your team is small, leaver volume is low and a documented manual deactivation step is acceptable.
- Choose SAML with SCIM when deprovisioning must follow authentik changes and your workspace is on Business+ or Enterprise.
- Plan the owner role: Name at least one owner who can complete setup and handle changes, regardless of which option you pick.
- Test the leaver path: Whichever option you choose, disable a test account in authentik and confirm the result in Slack.
- Record the decision: Keep a written note of the chosen plan, the reason and the people who can change it.
Before you choose, confirm current feature availability on Slack's pricing page, since plan details change.
Mapping authentik attributes, groups and identifiers to Slack accounts
This table lists the identity fields authentik sends to Slack in SAML assertions and SCIM requests, and the Slack-side setting each one must match. Read each row as a pair: the authentik source on one side, what Slack expects on the other. The main takeaway is that email, NameID and the SCIM external identifier decide whether accounts are matched or duplicated, so confirm those three in a test workspace before enabling provisioning.
| Mapping item | authentik source | Slack expectation | Verify before go-live |
|---|---|---|---|
| Email address | User email field, sent as a SAML attribute | Identifies the person; confirm which value Slack matches to existing accounts | Same address in both systems, including letter case and aliases |
| NameID format | Set on the SAML provider and sent for each user | Must match the format configured in Slack's SAML settings | Compare the format in the integration guide with the Slack SSO screen |
| Name attributes | Given name and family name from the user profile | Shown in the Slack profile after sign-in | Names appear correctly after a test sign-in |
| Group membership | Groups assigned to the user, sent only if the mapping includes them | Group values matter only if the Slack setup reads them | Confirm in the guide whether Slack uses groups for access or reporting |
| SCIM external identifier | Stable authentik user identifier used as the external ID | Links each Slack account to its authentik record across updates | Do not change the identifier after the first sync |
| SCIM attribute mapping | Property mappings choose which fields go into each SCIM user | Slack accepts only the user attributes its SCIM endpoint supports | Sync one test user and inspect the result before syncing a group |
| Deprovisioning key | Deactivating the user or removing the group in authentik | Slack deactivates the matching account when SCIM reports the change | Confirm deactivation behavior for your Slack plan in a test workspace |
Deprovisioning leavers so access ends in both systems
SAML decides who can sign in, but it does not remove a Slack account when someone leaves. The cards below cover the parts that have to work together: disabling the person in authentik, using SCIM deactivation where the Slack plan allows it, handling owners and guests, and checking that a leaver is actually locked out.
Why SAML alone leaves accounts active
SAML sign-in only happens when a user starts a login. If authentik stops issuing assertions for a person, an existing Slack account still exists, its member record stays in the workspace, and it can still appear in member lists and channels. Treat SAML as the sign-in gate and SCIM as the account lifecycle. Confirm with your Slack admin what the workspace shows for a deactivated member before you rely on it.
Confirm the SCIM plan requirement
Optional SCIM provisioning needs Slack Business+ or Enterprise, plus an app that carries the admin OAuth scope. On a Pro or Free workspace, deprovisioning cannot run through SCIM, so the leaver process must include a manual deactivation step. Check the plan before you design the workflow, because the plan decides whether leavers are removed automatically.
Disable the authentik user first
Deactivate the user in authentik as the first step of the leaver process, so the person can no longer authenticate through the Slack SAML provider. Remove or disable the user's active sessions where your authentik version supports it. Record the time of this step, because it is the point after which new Slack sign-ins should fail. Your offboarding ticket should name the authentik owner who performed it.
Remove group membership to trigger deprovisioning
SCIM deprovisioning follows the group and user state that authentik sends. Removing the user from the group bound to the Slack application is the path that tells the provisioning job to deactivate the Slack account. Verify in your own environment that removing a group member produces a deactivation event, not only a group update. Keep the group names stable so this change is predictable.
Handle workspace owners before offboarding
A Workspace or Org Owner is required for the SAML setup, and an owner account may not be deactivated the same way as a regular member. If the leaver holds owner rights, reassign ownership to a named active administrator first. Keep at least two owners so that one departure does not leave the workspace without an administrator who can change SSO settings.
Review guests and external accounts
Guests and Slack Connect members are not always covered by the same provisioning rules as internal members. Identify which accounts in the workspace use email domains outside your SAML-managed domain and decide whether each guest must be removed by hand. Document this list as part of every leaver review, since a guest left active is a common source of residual access.
Verify the leaver can no longer sign in
After the authentik and Slack steps, run a checklist: attempt a SAML login with the leaver's test or retired credentials, confirm the Slack member shows as deactivated, confirm they are gone from channels and user groups, and check that the authentik user and application assignment are disabled. Record the results with dates. Ask your Slack administrator which audit or member log entries prove the deactivation.
Common Slack and authentik SSO failures and how to fix them
This table lists the failures teams most often hit when connecting Slack to authentik over SAML and SCIM, with the likely cause, the fix and where to confirm the setting. Work down the rows in order when a sign-in or provisioning test fails, because several symptoms share the same root cause.
| Failure | Likely cause | Fix and where to confirm |
|---|---|---|
| Slack rejects the SAML response with an ACS or entity ID error | The ACS URL or entity ID copied into the authentik SAML provider differs from the values Slack expects, often by a trailing slash, http versus https, or a workspace URL typed from memory | Copy the ACS URL and entity ID exactly from the Slack SAML settings, then re-save the authentik provider. Confirm the values in the SAML provider configuration in authentik and in the Slack SSO settings page. |
| Sign-in fails after the signing certificate was rotated | authentik issued a new signing certificate or key, but Slack still holds the old certificate from the earlier upload | Export the current certificate from the authentik SAML provider and upload it to Slack again, then test with a non-admin account. Confirm the certificate fingerprint matches in both systems before closing the change. |
| SAML assertions are rejected intermittently | Clock skew between the authentik hosts or the user's device causes NotBefore or NotOnOrAfter checks to fail | Check time synchronization (NTP) on the authentik server and worker containers and on the host running them. Confirm the time source in the host operating system before changing SAML settings. |
| Users are blocked at sign-in with a domain or account message | The email address in the authentik user record uses a domain that is not verified or allowed for the Slack workspace, or the NameID does not match the Slack account email | Verify the domain in Slack, align the authentik user email with the Slack account, and confirm the NameID format and value sent in the SAML assertion. Confirm the attribute mapping on the authentik SAML provider. |
| SCIM provisioning returns authorization errors or no users appear | The Slack app was created without the admin OAuth scope, or the workspace plan does not include SCIM, so the token cannot manage accounts | Confirm the plan includes SCIM (the authentik Slack guide says Business+ or Enterprise), recreate the Slack app with the admin scope, and generate a new token in authentik. Confirm the scope list on the Slack app page. |
| Leavers keep access to Slack after deactivation in authentik | The user was deactivated in authentik, but the SCIM deactivation did not run or failed, and existing Slack sessions remain valid until they expire or are revoked | Check the SCIM sync logs and task status in authentik for failed deactivation calls, then deactivate the user in Slack directly if needed and revoke active sessions. Confirm the deprovisioning result on the Slack member list. |
| Slack plan or owner setup blocks the change | SAML is enabled by a Workspace or Org Owner, and a non-owner account cannot change the SSO configuration | Identify the owner account before the change window and keep a second owner available. Confirm the role on the Slack member profile and the plan on the Slack billing page. |
Questions buyers ask before configuring Slack SSO with authentik
Do we need to upgrade our Slack plan before setting up SAML with authentik?
It depends on the plan you run today. The authentik Slack guide says SAML SSO needs a Slack plan with custom SAML, and that optional SCIM provisioning needs Slack Business+ or Enterprise and an app with the admin OAuth scope. Slack's Free plan keeps 90 days of message and file history, and content on Free workspaces older than one year is permanently deleted, so check your retention needs before any change. Confirm the current plan features on Slack's pricing page and with your Slack account contact, since the cost of an upgrade is set by Slack, not by the integration work. Your Slack invoice is a recurring cost that continues after the integration is finished.
How long does it take to configure SAML and SCIM for Slack?
Duration depends on how many of the variables below are already settled. SAML alone is a bounded task once the Slack plan, the owner account and the authentik application exist, because it mainly involves matching the attribute mappings and testing sign-in. SCIM takes longer because it adds provisioning rules, group handling and a test cycle for creating, updating and deactivating accounts. We do not publish a duration for this work. Ask for a timeline in the written scope, and ask whether it covers a test tenant, a pilot group and a cutover window.
What internal work do identity and Slack admins need to provide?
Expect the work to split between two teams. Identity admins need to confirm which authentik groups should reach Slack, which attributes carry the user's email and name, and who owns the authentik application and its signing certificates. Slack admins need to hold a Workspace or Org Owner account, approve the custom SAML setup and decide how existing accounts map to identities. Both teams should agree on a leaver process, because deprovisioning depends on SCIM being connected to the same source of truth. Name a decision owner on each side before work starts so approvals do not stall the schedule.
Can our in-house team configure authentik and Slack without a partner?
A team with working authentik experience and a Slack owner account can often complete SAML alone, provided it can test sign-in safely. The harder parts are property mappings, SCIM token handling, and deprovisioning tests that prove a leaver loses access. Check three things honestly: whether someone on the team has run authentik in production, whether the team can test with non-owner accounts, and whether anyone owns the work after go-live. Your own team also carries the upgrade and monitoring load for authentik, which is a recurring cost even when the first setup is done in house.
What does a fixed-scope Slack SSO engagement include?
A fixed-scope engagement agrees in writing what is delivered before work starts. For this integration, a typical written scope lists the Slack plan assumption, the authentik provider and application configuration for SAML, the optional SCIM setup, the property mappings, a test plan covering sign-in and leaver deprovisioning, the handover documentation and the responsibilities of your identity and Slack admins. Ask that the scope name the environment, the test accounts and the acceptance criteria. DeployOpen does not publish a price list, so request a quote based on that written scope.
What drives the cost of a Slack SSO project up or down?
Cost follows the scope, and four factors move it most. The first is whether SCIM is in scope, since provisioning and deprovisioning add design and testing work. The second is the number of identity sources and groups that feed Slack. The third is how many Slack workspaces, Slack Connect channels or existing accounts need careful matching. The fourth is the state of your authentik deployment, including its version and how it is hosted. The authentik Docker Compose guide positions Compose for test setups and small-scale production, while the Kubernetes guide recommends a separately managed PostgreSQL for production, so an unplanned hosting change can add scope. Ask for each factor to be priced or excluded explicitly in the quote.
Is authentik free to use with Slack, and what recurs after go-live?
The authentik code is under the MIT license for most of the repository, while code in the enterprise directory is under a separate license, so confirm which features you use. The authentik pricing page lists Open Source at no cost, Enterprise at $5 per user per month billed annually plus $0.02 per external user per month, and Enterprise Plus starting at $20k annually. Slack's SAML and SCIM features depend on your Slack plan, so you may pay for Slack and for authentik support separately. Recurring costs include the Slack subscription, authentik upgrades, your hosting and database, and any support retainer you choose. Confirm with authentik which features your scope needs before deciding on a license tier.
How DeployOpen works on this
DeployOpen plans, implements, hardens, documents and supports self-hosted authentik inside your own infrastructure, and connects it to Slack over SAML with optional SCIM provisioning. Each engagement starts with a written scope that fixes what is delivered before work begins.
How we scope
- Confirm your Slack plan, Workspace or Org Owner account and whether SCIM is in scope before design starts
- Map which Slack roles, channels and user groups your identity groups must drive after sign-in
- Record the authentik version, PostgreSQL setup and hosting model your environment will run
- Agree deliverables, test cases and the leaver process in writing. Engagements are fixed-scope
How we build
- Configure the authentik SAML provider and Slack application, with attribute and property mappings documented
- Build SCIM provisioning only where the plan and admin OAuth scope allow it, with a tested rollback path
- Test SSO logins, first-login account behavior, group changes and deprovisioning on a non-production workspace
- Keep configuration as code where your team wants it, so changes can be reviewed and repeated
How we hand over
- Deliver runbooks for the Slack and authentik settings, owner account custody and break-glass access
- Document the deprovisioning procedure for leavers, including how sessions and workspace access are ended
- Walk your administrators through verification checks and the evidence they should keep for reviews
- Provide a clear list of open items that depend on Slack or authentik behavior you must confirm yourself
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after handover
- Plan authentik upgrades and retest the Slack sign-in and provisioning flow after each change
- Review Slack plan or policy changes that could affect SSO or SCIM and agree updates in writing
- Keep the retainer scope written so response expectations are clear before any incident occurs
