Single sign-on (SAML)
Connect your identity provider (Okta, Entra ID, Google) so your team signs in via SAML, with JIT provisioning.
Let your team sign in to error.page with your company's identity provider. error.page acts as a SAML 2.0 service provider (SP); you connect it to your identity provider (IdP) — Okta, Microsoft Entra ID (Azure AD), Google Workspace, OneLogin, or any SAML 2.0 IdP. Single sign-on is available on the Business plan and is configured per organization by an owner or admin.
Setting up SSO? Talk to us first. While SAML is in early access we set it up with you. Email support@error.page and we'll schedule a short call to configure your identity provider together and confirm the first sign-in live — so you're never debugging SAML alone. The self-service steps below are the same ones we'll walk through.
How it works
- A member visits your organization's SSO login URL (or clicks your app tile at the IdP).
- They authenticate at your IdP.
- The IdP posts a signed assertion back to error.page. We verify the signature, read the user's email, and sign them in.
- If the person doesn't have an account yet and just-in-time (JIT) provisioning is on, we create one and add them to your organization automatically.
Because the assertion is cryptographically signed by your IdP, no password is stored for SSO users.
Step 1 — Register error.page at your IdP
Open Team → Single Sign-On (SAML). You'll find the service-provider details to enter at your IdP:
| Field | Value |
|---|---|
| SP Entity ID | https://error.page/saml/{org}/metadata |
| ACS (Reply) URL | https://error.page/saml/{org}/acs |
| Metadata URL | https://error.page/saml/{org}/metadata |
| NameID format | emailAddress |
Most IdPs let you paste the Metadata URL to import all of these at once. The NameID must be the user's email address.
Step 2 — Enter your IdP details
Back on the SSO settings page, provide:
- IdP Entity ID / Issuer — your IdP's identifier.
- IdP SSO URL — the SAML 2.0 sign-in endpoint your IdP redirects to.
- IdP X.509 certificate — the public signing certificate. We use it to verify every assertion.
Then choose:
- Default role for people who join via SSO (Member or Admin).
- JIT provisioning — whether to auto-create accounts on first sign-in.
Step 3 — Enable it
Tick Enable SSO and save. SSO stays off until the entity ID, SSO URL, and certificate are all present — so a half-finished configuration can never lock anyone out. Once active, use Test login on the settings page to confirm the round-trip before rolling it out.
Signing in
- SP-initiated: send members to
https://error.page/saml/{org}/login. - IdP-initiated: members click your error.page tile in the IdP's app portal, which posts straight to the ACS URL.
Notes
- SSO is enforced per organization and gated to the Business plan; if the plan lapses, the SSO endpoints stop accepting sign-ins.
- New SSO accounts are marked email-verified (your IdP asserted the identity) and are added with the default role you chose.
- Existing accounts are linked, not duplicated — if someone already signed up with the same email, SSO simply signs them into your organization.
- Rotating your IdP certificate? Paste the new certificate on the settings page; verification switches over on save.