SilentChat

SAML SSO

SAML 2.0 is the right choice once your organization runs an Identity Provider — Okta, Azure AD, Google Workspace, OneLogin, JumpCloud. SilentChat acts as the Service Provider and accepts signed SAML assertions.

When SAML — when not

SilentChat supports several login methods side by side. SAML isn't right for everyone.

  • Password — Classic email + password. Default for small teams without an IdP.
  • Google OAuth — One-click login with a Google account. Good for Workspace customers without a SAML license.
  • Magic link — Passwordless login via signed email link. Made for portal users and infrequent logins.
  • SAML SSO — If you have compliance requirements (ISO 27001, SOC 2), need centralized offboarding, or enforce MFA via your IdP — pick SAML.

Service Provider configuration

Plug these URLs into your IdP. They're tenant-specific — find your tenant ID in Settings → SSO.

  • SP Entity ID: https://app.silentchat.de/saml/{tenant_id}
  • ACS URL: https://api.silentchat.de/api/v1/auth/saml/acs/{tenant_id}
  • Metadata URL: https://api.silentchat.de/api/v1/auth/saml/metadata/{tenant_id}
  • Login Initiator: https://api.silentchat.de/api/v1/auth/saml/login/{tenant_id}

You can also point your IdP at our metadata URL to auto-pull the SP configuration.

IdP setup checklist

In Settings → SSO, paste your IdP's connection details. Four fields are required.

  • IdP Entity ID — Issuer URL of your IdP — e.g. https://sts.windows.net/YOUR-TENANT-ID/ on Azure.
  • IdP SSO URL — Login endpoint of your IdP, where auth requests are sent.
  • X.509 certificate — PEM-encoded public-key certificate for verifying assertion signatures. Required.
  • IdP SLO URL (optional) — Single-Logout endpoint. Only set this if your IdP supports SLO.

Attribute mapping

Default attributes are email, firstName, and lastName. If your IdP uses different attribute names, override the mapping in SSO settings.

  • email — Required. Uniquely identifies the user.
  • firstName — First name for the UI.
  • lastName — Last name for the UI.

Sample assertion using the default mapping:

<saml:AttributeStatement>
  <saml:Attribute Name="email">
    <saml:AttributeValue>jane.doe@acme.com</saml:AttributeValue>
  </saml:Attribute>
  <saml:Attribute Name="firstName">
    <saml:AttributeValue>Jane</saml:AttributeValue>
  </saml:Attribute>
  <saml:Attribute Name="lastName">
    <saml:AttributeValue>Doe</saml:AttributeValue>
  </saml:Attribute>
</saml:AttributeStatement>

Just-in-Time provisioning

When auto_provision is enabled (the default), SilentChat creates users automatically on their first successful SSO login. No pre-sync, no manual user creation.

  • Default role for JIT users: agent. Switchable to any other system role in SSO settings.
  • Re-provisioning: every login refreshes firstName/lastName from the assertion — your IdP stays the source of truth.
  • Disabling a user in the IdP takes effect immediately on the next login attempt; existing sessions expire with the configured token TTL.

Enforce SSO

"Enforce SSO" disables password and OAuth login for every tenant member except the Owner. Safety net: the Owner can always fall back to password login if the IdP is down.

Troubleshooting

  • "Invalid signature" — The certificate stored in SilentChat doesn't match the one your IdP signs with. Re-export the cert from the IdP and paste it again.
  • "Email attribute missing" — Your IdP sends the email under a different attribute name. Adjust the attribute mapping — e.g. to NameID or mail.
  • Login redirect loop — ACS URL in the IdP usually has a typo. Copy it from SSO Settings → ACS URL and paste it verbatim into the IdP.
  • Replay-attack error — An assertion was already processed (replay protection triggered). Only happens when the browser submits the login twice — clear the browser cache or restart the flow.
SAML SSO | SilentChat