Authaz logoAuthaz
DocumentationAPI Reference
  • Get Started

    • Authaz
    • Core Concepts
    • Set up your app
    • Quickstart — cURL
  • Authentication

    • Authentication Settings
    • Signup
    • Invitations
    • Password Authentication
    • Multi-Factor Auth
    • Magic Link
    • OAuth / Social Login
    • Passkey (WebAuthn)
    • SAML SSO
    • Machine-to-Machine (M2M)
    • API Keys
  • Authorization

    • Authorization
    • Resources
    • Policies
    • Roles
    • Access Explorer
  • Tenancy

    • Multi-tenancy
    • Tenancy Customization
  • Brand & Host

    • Branding
    • Custom Domains
    • Communications & Email Templates
  • Operate

    • Users
    • Analytics
    • Audit Logs
    • Application Settings
  • SDK Quickstarts

    • Quickstart — Next.js
    • Quickstart — React SPA
    • Quickstart — Hono
    • Quickstart — .NET (Authaz.Sdk)
  • Recipes

    • Recipes & Cookbook
    • Next.js — first integration
    • Next.js — B2B SaaS (multi-tenant)
    • Hono — first integration
    • Hono — B2B SaaS (multi-tenant)
    • React SPA — first integration
    • React SPA — B2B SaaS (multi-tenant)
    • .NET — first integration
    • .NET — B2B SaaS (multi-tenant)
  • Reference

    • Tokens
    • API Reference
    • Errors & Troubleshooting
  • Documentation

    • How Authaz is Built
  1. Authaz
  2. Docs
  3. Authentication
  4. SAML SSO

Authentication

SAML SSO

4 min read·Updated Jun 19, 2026

The SAML SSO card under Application → Authentication lets enterprise customers sign in through their own identity provider — anything that speaks SAML 2.0. Authaz acts as the Service Provider (SP); the customer's IdP issues the assertion.

Use it in your app. Once a SAML connection is configured, users at that domain are routed to their IdP automatically — your app code doesn't change. The standard sign-in flow (Next.js · React · Hono · cURL) returns the same OAuth tokens regardless of how the user authenticated.

# Create a SAML connection
curl -X POST https://your-app.authaz.io/api/v1/applications/{appId}/auth/saml/connections \
  -H "X-API-Key: $AUTHAZ_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Acme Corp IdP",
    "entityId": "https://your-app.authaz.io/saml/{connectionId}",
    "ssoUrl": "https://idp.acme.com/sso/saml",
    "x509Certificate": "-----BEGIN CERTIFICATE-----\nMIID...\n-----END CERTIFICATE-----",

Previous
Passkey (WebAuthn)
Next
Machine-to-Machine (M2M)
"tenantId": "tenant_acme"
}'

Where it lives#

Dashboard → Application → Authentication → SAML SSO. The list page shows every connection; click one to edit its metadata, attribute mapping, and signing certs.

How it works#

┌─────────────────┐  1. user clicks Sign in    ┌─────────────────┐
│ Authaz Sign-In │ ────────────────────────▶  │  Customer IdP   │
│  (Authaz SP)    │                            │  (IdP)          │
└────────┬────────┘                            └────────┬────────┘
         ▲                                              │
         │ 4. SAML response                             │ 2. user
         │   posted back                                │    authenticates
         │                                              ▼
         │                                      ┌─────────────────┐
         └──────────────────────────────────────│  IdP signs &    │
                  3. browser redirects with     │   posts the     │
                     SAML assertion             │   assertion     │
                                                └─────────────────┘
  1. User clicks the application's SAML button on Authaz Sign-In (or hits a tenant-specific subdomain that auto-routes to the SP).
  2. Authaz redirects the browser to the IdP's SSO URL with an AuthnRequest.
  3. User authenticates at the IdP, which posts a signed AuthnResponse back to Authaz's ACS URL.
  4. Authaz validates the signature, extracts the user's email and attributes, creates or finds the user, and signs them in.

From the application's perspective it's the same as any other login — the user lands back with an authorization code, your backend exchanges it for tokens.

Setup#

1. Create a connection in Authaz#

This generates the SP metadata (entity ID, ACS URL, signing cert) you'll hand to the customer.

curl -X POST https://your-app.authaz.io/api/v1/applications/{appId}/auth/saml/connections \
  -H "X-API-Key: $AUTHAZ_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Acme Corp IdP",
    "tenantId": "tenant_acme"
  }'

Response includes:

{
  "id": "saml_01h...",
  "spEntityId": "https://your-app.authaz.io/saml/saml_01h...",
  "spAcsUrl":   "https://your-app.authaz.io/auth/saml/saml_01h.../acs",
  "spMetadataUrl": "https://your-app.authaz.io/auth/saml/saml_01h.../metadata"
}

Or download SP metadata XML from the dashboard for the customer to upload to their IdP.

2. Configure the IdP#

The customer creates a SAML application in their IdP using your SP details:

FieldValue
Single Sign-On URL (ACS)spAcsUrl from above
Audience URI / SP Entity IDspEntityId
Name ID FormatEmailAddress (recommended)
Attribute Statementsemail, firstName, lastName (and any custom attrs you map)

The customer hands you back:

  • IdP SSO URL — where Authaz redirects the user.
  • IdP entity ID — used to validate the assertion.
  • X.509 signing certificate — the IdP's public key.

3. Plug the IdP details into the connection#

curl -X PATCH https://your-app.authaz.io/api/v1/applications/{appId}/auth/saml/connections/{connectionId} \
  -H "X-API-Key: $AUTHAZ_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "ssoUrl": "https://idp.acme.com/sso/saml",
    "idpEntityId": "https://idp.acme.com/saml/metadata",
    "x509Certificate": "-----BEGIN CERTIFICATE-----\nMIID...\n-----END CERTIFICATE-----"
  }'

The connection is now usable. The next user who hits SAML for this connection will be redirected to the IdP, authenticate, and come back authenticated.

Attribute mapping#

By default Authaz reads:

Authaz user fieldSAML attribute (default)
emailNameID (when format is EmailAddress) or email
namedisplayName, falling back to firstName + lastName
firstNamefirstName or givenName
lastNamelastName or surname

Override mappings per connection if the IdP sends different attribute names:

{
  "attributeMapping": {
    "email": "EmailAddress",
    "firstName": "user.firstName",
    "lastName": "user.lastName",
    "department": "user.department"
  }
}

Custom attributes (like department above) are written to the user's metadata object — you can then read them from the access token's user_metadata claim.

Per-tenant connections (multi-tenant apps)#

Most enterprise scenarios are: each tenant has one IdP. Set tenantId on the connection and Authaz will scope it.

Authaz Sign-In auto-routes the user to the right connection based on their email domain. Set domains on the connection:

{
  "domains": ["acme.com", "acme.io"]
}

Now, anyone signing in with an @acme.com address is sent through Acme's IdP automatically. Other domains either fall back to other authentication methods or, if the application is SAML-only, get a "no SSO connection found" error.

Just-in-time provisioning#

When a user logs in via SAML for the first time, Authaz creates the user record on the fly using the email from the assertion. They're assigned the connection's defaultRoles:

{
  "defaultRoles": ["role_member"]
}

For shared-pool multi-tenancy, the user is also added to the connection's tenant on first sign-in.

Signed/encrypted assertions#

By default Authaz validates the assertion's signature against the IdP's certificate. For higher security you can also require:

  • Signed AuthnRequest — Authaz signs the request to the IdP. Set signRequests: true and download the SP signing cert from the connection.
  • Encrypted assertions — IdP encrypts the assertion to Authaz's public key. Set encryptAssertions: true.

Both are optional and require IdP support.

Connection statuses#

StatusMeaning
draftCreated but missing IdP details. Not usable for sign-in yet.
activeFully configured and live.
disabledManually disabled — sign-ins through this connection return an error.
errorLast assertion failed validation; check the audit log for the reason.

Next steps#

  • Multi-tenancy — how tenant-scoped connections work in shared vs isolated pools.
  • Users — JIT-provisioned users show up here just like any other user.
  • Audit Logs — every SAML assertion (success and failure) is logged.