SafeWeb API
SSO

Single sign-on (SSO)

Overview

SafeWeb customer portals use a managed authentication service for identity and sessions. Partners can sign customers in through one of two approaches:

OptionBest for
Enterprise SSOCustomers who must authenticate through your corporate identity provider (SAML 2.0)
Magic linkEmbedded or partner-hosted flows where you obtain a one-time login URL via the Partner API

Both paths result in a standard SafeWeb session (JWT access and refresh tokens) for the customer in the portal.

Choosing an approach

ConsiderationEnterprise SSOMagic link
SetupConfigured by SafeWeb per partnerSelf-serve via Partner API
Customer experienceSign in at your IdP (Okta, Entra, etc.)Open a one-time URL you deliver from your app
Policy controlMFA, conditional access, and session rules at your IdPLink expiry and portal session limits on SafeWeb
Typical useMandated corporate IdP, regulated industries“Open dashboard” from your portal, post-onboarding deep links

You can use both for different customer segments. Enterprise SSO does not replace the magic link API for partners who need programmatic sign-in from their own applications.

Terminology

TermMeaning
CustomerEnd user monitored on SafeWeb. Has a platform user account created during onboarding (from the customer's contact email).
PartnerYour integration organization. Authenticates Partner API calls with SW-PARTNER-ID and SW-API-KEY.
SessionAuthenticated state in the customer portal, backed by access and refresh tokens.
Magic linkA passwordless, one-time sign-in link. Opening it verifies a token and creates a session.
Enterprise SSOSign-in through your IdP using SAML 2.0. SafeWeb acts as the service provider and trusts assertions configured for your partner.
IdPIdentity provider — your SSO system (e.g. Okta, Microsoft Entra, Google Workspace).
SPService provider — SafeWeb, which accepts SAML assertions from your IdP.
AssertionSigned statement from your IdP about the authenticated user (identity, email, optional attributes).
NameIDStable identifier for the user in the SAML assertion, often their email address.
ACS URLEndpoint where your IdP sends the SAML response after the user signs in.

Sessions

After either sign-in method succeeds, the customer receives a portal session:

  • Access tokens are short-lived (typically one hour). The portal refreshes the session using a refresh token while the customer remains active.
  • Enterprise SSO sessions may also be limited by your IdP (session lifetime, forced re-authentication, or group policy). SafeWeb honours those limits when the IdP enforces them.
  • Sign-out from the portal ends the SafeWeb session. Single logout (SLO) back to your IdP is not supported; customers who need to re-authenticate should sign out of the portal or rely on IdP session policies.

How it fits together

flowchart LR
  partner[Partner backend]
  api[Partner API]
  auth[SafeWeb Auth]
  portal[Customer portal]
  partner -->|"magic link request"| api
  api -->|"create magic link"| auth
  api -->|"returns url"| partner
  partner -->|"deliver url to customer"| portal
  portal -->|"verify token"| auth

Enterprise SSO

sequenceDiagram
  participant Customer
  participant Portal as SafeWeb portal
  participant IdP as Your IdP
  Customer->>Portal: Sign in with SSO
  Portal->>IdP: Redirect (SAML AuthnRequest)
  IdP->>Customer: Authenticate (MFA, policy, etc.)
  IdP->>Portal: SAML assertion (ACS)
  Portal->>Customer: Session established

For enterprise SSO, the customer is redirected to your IdP instead of using the magic link API. SafeWeb configures the SAML connection when you are ready to go live.

Guides

Partner API authentication

Magic link generation uses the same headers as other /api/v1/integrations/... endpoints. See the Partner API overview for credentials and environment URLs.

On this page