Slack SSO with MojoAuth

Configure Slack to authenticate members through MojoAuth using SAML 2.0. MojoAuth acts as the Identity Provider (IdP) and Slack acts as the Service Provider (SP) — members sign in to Slack with their MojoAuth-managed identity instead of a Slack password.

How it works

Slack supports both flows:

SP-initiated — a member goes to the workspace URL and clicks "sign in with SSO," Slack redirects to MojoAuth's SSO URL.
IdP-initiated — a member starts from MojoAuth's hosted login / app dashboard and lands directly in Slack (use the connection's Test SSO button to simulate this).

⚠️

Slack SSO with SAML requires a Business+ or Enterprise Grid plan. It is not available on Free, Pro, or standard Enterprise (non-Grid) plans. Confirm your workspace's plan before starting.

Prerequisites

A MojoAuth project (test or live) with access to Developers → Applications.
A Slack Business+ workspace, or an Enterprise Grid org, with owner or admin access.
The workspace URL, e.g. https://your-team.slack.com.
A way to reach the workspace as an owner/admin if something goes wrong after enabling SSO (see Troubleshooting — do not lock yourself out).

Step 1 — Create the MojoAuth SAML connection

Create a new SAML connection

In the MojoAuth dashboard, go to Developers → Applications → New Application → SAML 2.0 SSO. Enter a connection name (e.g. Slack — Acme Workspace) and click Create connection. This creates a draft connection and auto-issues a signing certificate.

Copy the IdP values

On the connection page, copy these values — you'll paste them into Slack in Step 2:

Value	URL
IdP metadata URL (Identity Provider Issuer)	`{BASE}/saml/{projectId}/sps/{spId}/metadata`
IdP SSO URL (SAML 2.0 Endpoint)	`{BASE}/saml/{projectId}/sps/{spId}/sso`
IdP SLO URL (logout, optional)	`{BASE}/saml/{projectId}/sps/{spId}/slo`
IdP signing certificate	Use Copy PEM (or Download .crt) on the connection page

The IdP Entity ID is the same as the IdP metadata URL above.

For background on connections, see SAML SSO Connections.

Step 2 — Configure Slack

Open Slack's authentication settings

As a workspace owner or admin, go to Settings & administration → Workspace settings (from the workspace name menu in the top left), then open the Authentication tab and find SAML. Click Configure.

If you manage an Enterprise Grid org, do this from the org-level admin settings so the policy applies across all workspaces in the org, or per-workspace if you only want it scoped to one.

Choose Custom SAML 2.0

Slack offers a few pre-built SAML options for specific IdPs. Since MojoAuth isn't in that list, choose "Custom SAML 2.0".

Enter MojoAuth's IdP values

Fill in Slack's SAML configuration form with the values you copied in Step 1:

Slack field	Value
SAML 2.0 Endpoint (HTTP)	MojoAuth IdP SSO URL — `{BASE}/saml/{projectId}/sps/{spId}/sso`
Identity Provider Issuer	MojoAuth IdP Entity ID (metadata URL) — `{BASE}/saml/{projectId}/sps/{spId}/metadata`
Public Certificate	Paste the PEM copied from MojoAuth's Copy PEM button

Slack's certificate field expects the full PEM block, including the -----BEGIN CERTIFICATE----- and -----END CERTIFICATE----- lines, with no extra whitespace or line-wrapping changes. Use Copy PEM rather than retyping from a downloaded .crt to avoid formatting issues (see Troubleshooting).

Note Slack's Service Provider values

Slack shows its own SP values on the same screen — you'll need to send these back to MojoAuth in Step 3:

Slack SP value	Typical value
ACS URL (Assertion Consumer Service)	`https://your-team.slack.com/sso/saml`
SP Entity ID	`https://slack.com` (some workspaces show the workspace URL instead — use exactly what Slack displays)

Always copy these directly from your Slack screen rather than assuming the values above — Slack occasionally shows the workspace-specific URL as the Entity ID instead of https://slack.com.

Don't save yet

Leave this Slack tab open (or come back to it) — you'll finish the Test SSO and enforcement settings in Step 5, after MojoAuth has the SP details from Step 3.

Step 3 — Give Slack's SP details back to MojoAuth

Enter the SP Entity ID and ACS URL

Back on the MojoAuth connection page, use Import from metadata if Slack exposes a metadata URL for your setup, or use Manual configuration and enter:

SP Entity ID — the value from Slack's SP screen (e.g. https://slack.com)
ACS URL — https://your-team.slack.com/sso/saml

Set the NameID format

Set NameID format to emailAddress — Slack matches incoming SSO members to existing accounts (or provisions new ones) by email address.

Save the connection

Click Save. The connection now has both the IdP details Slack needs and the SP details MojoAuth needs to issue a valid assertion.

Step 4 — Attribute mapping

Slack reads identity fields from the SAML assertion's attribute statements (in addition to NameID for email matching). Configure these rows in the connection's Attribute mappings:

`saml_name` (Slack expects)	`source` (MojoAuth field)	`name_format`
`User.Email`	`email`	`basic`
`first_name`	`firstName`	`basic`
`last_name`	`lastName`	`basic`

Example resulting assertion attributes for a user:

<saml:AttributeStatement>
  <saml:Attribute Name="User.Email" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
    <saml:AttributeValue>jane.doe@acme.com</saml:AttributeValue>
  </saml:Attribute>
  <saml:Attribute Name="first_name" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
    <saml:AttributeValue>Jane</saml:AttributeValue>
  </saml:Attribute>
  <saml:Attribute Name="last_name" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
    <saml:AttributeValue>Doe</saml:AttributeValue>
  </saml:Attribute>
</saml:AttributeStatement>

User.Email must match the member's email in Slack exactly (case-insensitive). If Slack can't match the email to an existing member and your workspace doesn't allow SSO-based provisioning, sign-in will fail — see Troubleshooting.

Step 5 — Test

Test from MojoAuth (IdP-initiated)

On the MojoAuth connection page, click Test SSO. This simulates an IdP-initiated login: MojoAuth builds a signed assertion and posts it straight to Slack's ACS URL. A successful test lands you on the Slack workspace, signed in.

Test from Slack (SP-initiated)

In an incognito/private browser window, go to your workspace URL (https://your-team.slack.com) and choose sign in with SSO (or Slack will auto-redirect if SSO is enforced). You should be redirected to MojoAuth's login, authenticate, and land back in Slack signed in as the matching member.

Confirm before enforcing

Back in Slack's SAML settings, you'll see options to require SSO for all members and to set session expiry ("expire session after X days" or similar). Before turning on "Require SSO":

⚠️

Keep at least one workspace owner able to sign in without SSO (e.g. via a password + email fallback, or Slack's documented emergency bypass) until you've verified SSO works for multiple test members. If SSO is misconfigured and enforced with no fallback, admins can be locked out of the workspace entirely.

Once you've confirmed a few successful logins, enable "Require SSO" so members can no longer sign in with a plain Slack password, and set the session expiry policy your org wants.

Troubleshooting

"Invalid certificate" or Slack rejects the SAML response

Slack is strict about the Public Certificate field formatting. Use the Copy PEM button on the MojoAuth connection page rather than opening a downloaded .crt in a text editor — line-ending changes, extra blank lines, or a missing BEGIN/END CERTIFICATE wrapper will cause Slack to reject the certificate or fail signature validation. If you rotate the MojoAuth signing certificate later, you must re-paste the new PEM into Slack — there's no automatic sync.

"We were unable to find an account for that email" (email mismatch)

Slack matches the SAML User.Email attribute (or NameID) against existing member emails. Check that:

The User.Email mapping's source is email, not identifier or another field.
The MojoAuth user's email matches, exactly, the email Slack has on file for that member (aliases or secondary emails aren't matched automatically).
If you expect Slack to auto-provision new members on first SSO login, confirm your Slack plan/settings allow SSO-based account creation — otherwise the member must already exist in the workspace.

"Invalid Audience" / "Invalid Issuer" (entity ID or ACS mismatch)

This means the SP Entity ID or ACS URL saved on the MojoAuth connection doesn't match what Slack actually sent in the AuthnRequest (or is validating against). Re-check the exact values Slack shows on its SAML configuration screen — some workspaces use https://slack.com as the Entity ID and others show the workspace-specific URL. Copy it character-for-character rather than assuming the default.

SP-initiated login redirects but never completes

Usually the SAML 2.0 Endpoint (IdP SSO URL) pasted into Slack is wrong (typo, wrong {spId}, or pointing at a different MojoAuth project/environment than the one with the attribute mappings you configured). Re-copy the IdP SSO URL from the connection page and confirm it matches exactly.

"It works when I test it, but other members can't log in"

The Test SSO button and IdP-initiated logins use MojoAuth's own session — they don't prove SP-initiated login works for a member who has never signed in. Test SP-initiated in an incognito window with a real (non-admin) test member's credentials before enforcing SSO for the whole workspace.

Locked out after enabling "Require SSO"

If every admin is now forced through a broken SSO flow, Slack support can help temporarily disable SSO enforcement for the workspace with proof of ownership, but this is slow. Avoid it by always keeping one verified owner account able to bypass SSO (per Slack's documented process) until SSO has been confirmed working end-to-end for regular members.