If your customers are organisations, their staff can sign in to your app with the account their organisation already gives them. You add a connection to the organisation's identity provider, over SAML 2.0 or OpenID Connect, and list the email domains it covers.
How users reach a connection
When a project has an enabled connection with at least one email domain, the hosted login page shows Continue with single sign-on.
The user enters their work email address. Only the part after the @ is sent to auth4.dev, which looks up the connection for that domain.
The browser goes to the organisation's IdP, the user signs in there, and the IdP sends them back. auth4.dev checks the answer and continues the sign-in as for any other method.
Each domain belongs to one connection in a project. Listing a domain only decides where users are sent; it doesn't prove that the organisation owns the domain. An email address is marked verified only when it is at one of the connection's domains.
Add a SAML 2.0 connection
On the project's sign-in methods page, under Enterprise single sign-on:
Select Add connection, choose SAML 2.0, give it a name (for example the organisation's name) and list its email domains, separated by commas.
From the organisation's IdP, copy its entity ID (also called the issuer), its single sign-on URL for the HTTP-Redirect binding and itssigning certificate in PEM format. Paste them into IdP entity ID,Single sign-on URL and IdP signing certificate.
Save. The connection card now shows the values the IdP administrator needs:
Audience (SP entity ID), the value the IdP must put in the assertion's audience;
Assertion Consumer Service URL, where the IdP posts its answer (also called the reply URL), using the HTTP-POST binding;
SP metadata URL, which many IdPs can import instead.
They look like this, with your project and connection IDs:
Ask the IdP administrator to send a persistent user identifier as the NameID, or the user's email address, and to include an email attribute if the NameID isn't the address. Transient NameIDs change at every sign-in and are refused.
Tick Offer this connection on the hosted login, or select Enable on the card, when the IdP side is ready.
What auth4.dev accepts
Only answers to a sign-in that started on the hosted login page. IdP-initiated sign-in, where the user starts from the IdP's app list, isn't supported.
The assertion, or the whole response, must be signed with RSA and SHA-256 or SHA-512, by the certificate saved on the connection. SHA-1 signatures and certificates sent inside the response aren't accepted. Encrypted assertions aren't supported.
The assertion must name the audience above, be addressed to the Assertion Consumer Service URL, and be used within its validity period (with two minutes allowed for clock differences). Each assertion can be used once.
When the IdP rotates its signing certificate, paste the new certificate into Replace signing certificate (optional) and save. The old one stops working at once. The card warns you 30 days before the saved certificate expires.
Add an OpenID Connect connection
At the organisation's IdP, register a web application. Use this redirect URI; the console shows the exact value, with your IDs, on the connection card after you save:
Copy the application's client ID and client secret.
Open the IdP's discovery document, at /.well-known/openid-configuration under its issuer, and copy issuer, authorization_endpoint,token_endpoint and jwks_uri.
In the console, select Add connection, choose OpenID Connect, and fill in the name, domains, the four values above, the client ID and the client secret. Most IdPs accept the default Token endpoint authentication; choose Form body if yours asks for client_secret_post.
Save, register the redirect URI shown on the card if you haven't yet, and enable the connection.
auth4.dev asks for openid email profile, uses PKCE and a nonce, and accepts only an ID token signed with RS256 or ES256 by the IdP's published keys, issued by exactly the issuer you entered, for your client ID. The client secret is stored encrypted and can't be viewed again. To change the client ID, enter its secret too.
What identity data you get
Each user is identified by the connection and the IdP's identifier for them (the SAML NameID or the OIDC sub). Your application receives the usual auth4.dev sub; key your data by that.
The email address is stored when the IdP sends one. It is marked verified only at one of the connection's domains, and for OpenID Connect only if the IdP didn't say it is unverified. Under the default setting, the verified email step asks for an address only when it isn't verified. The IdP's address never becomes theemail claim; only an address verified with auth4.dev does.
A single sign-on account and any other sign-in method are separate users, even with the same email address. They are joined only through account linking in the email step. Users of different connections are separate too.
Owners and admins can add, edit, enable, disable and delete connections; viewers see them read-only. Every change, and every refused change, is recorded in the project's audit log, as are single sign-on sign-ins and refused answers, with a short reason such as audienceor assertion_replayed. Secrets, certificates and user details aren't recorded.
Deleting a connection stops sign-ins through it at once. The users who signed in through it keep their accounts, but can't sign in to them that way again. A connection added later, even for the same IdP, creates new users. A project can have up to 10 connections with up to 20 domains each.
API reference
The management routes, the sign-in routes and the exact checks are in the API reference.