Let the employees of your business customers sign in with their corporate credentials through Okta, Microsoft Entra ID, or any other SAML identity provider that you connect in the Conjoin Console.
Auth accepts sign-ins from Okta, Microsoft Entra ID, and the other identity providers that your enterprise customers use. The identity provider confirms who each employee is, while you manage their roles, permissions, and user records in your own Auth project.
Give each organization its own SAML connection to the customer's identity provider. Auth checks every SAML assertion against that provider's signing certificate and picks up the new certificate when the provider rotates it.
For identity providers that use OpenID Connect, Auth signs employees in through the authorization code flow with PKCE.
Auth syncs users and groups from each customer's directory, then creates, updates, or deactivates an account as each employee joins, changes role, or leaves.
At an employee's first SSO sign-in, Auth builds their account from the name, the email address, and the other attributes that the identity provider sends.
Auth applies the session policy that the identity provider sets. With single logout (SLO), a user who signs out of one application ends their session in every application on that connection.
Once a customer verifies their email domain, Auth sends every user with an address on that domain to the organization's SSO connection to sign in.
Generate a portal link with one API call or in the Conjoin Console, then send it to your customer so that their IT administrator can connect their identity provider to Auth.
In the portal, the customer uploads their SAML metadata and tests the connection. Auth accepts SSO sign-ins from that customer's employees as soon as the customer activates the connection.
Once a customer verifies their email domain, Auth sends every user with an address on that domain to the organization's SSO connection to sign in.
Generate a portal link with one API call or in the Conjoin Console, then send it to your customer so that their IT administrator can connect their identity provider to Auth.
In the portal, the customer uploads their SAML metadata and tests the connection. Auth accepts SSO sign-ins from that customer's employees as soon as the customer activates the connection.
Accounts that Auth creates at the first SSO sign-in
Standard that Auth uses to sync users and groups
Sign-in standards that Auth accepts from identity providers
Upload the identity provider's metadata to the Conjoin Console to create a SAML or OIDC connection. Auth sets up certificate rotation, attribute mapping, and error handling for that connection by default, so you change nothing when the provider rotates its signing certificate.
When an enterprise buyer requires SAML or OIDC SSO in their security review, you can show them a working connection in the Console.
With just-in-time provisioning, Auth creates an employee's account the first time that they sign in through their identity provider. Auth then assigns their roles, team memberships, and permissions from their groups in the directory.
Auth also creates accounts before the first sign-in when the customer's directory sends them over SCIM. With the SCIM token of that directory connection, the sample lists those accounts in the Saltrun Climate project and prints each user name with its active flag and its SCIM metadata, which includes the creation time.
Prompt for a coding agent: List the accounts that the Saltrun Climate directory sends over SCIM, with each active flag.
Select a file to view its contents
Auth detects a deactivation in the customer's directory within the sync interval that you configure and then revokes the employee's access in every application connected to Auth. Auth also updates an employee's permissions as soon as a change to their group membership comes in from the directory.
With one deprovisionAccount call, the sample revokes Layla Sayegh's sessions, tokens, and active grants in a single operation, which Auth records in its audit log. You can show that audit entry as evidence of deprovisioning in a SOC 2 or ISO 27001 access review.
Prompt for a coding agent: Revoke every session, token, and grant of an employee who leaves, in one call.
Select a file to view its contents
When a customer verifies their email domain, SSO becomes the only sign-in method that Auth offers to the addresses on that domain. Users with addresses on other domains can still sign in with a password or a social login.
The identity provider applies the customer's conditional access, MFA, and session policies to every sign-in from that domain, so the customer can show an auditor that their whole domain requires SSO.
Your part of the setup is one portal link for the customer's organization, which you generate in the Conjoin Console or through the API. The customer's IT administrator completes the rest in the portal, where they enter the details of their identity provider and confirm that a test sign-in succeeds.
Auth stores the finished connection with the customer's organization, so you can turn on SSO for a new customer with no deploy of your application.
Conjoin will open with a free Build tier, while the pricing page already lists the launch prices for Pro and Business. If you tell us what you're building, we'll talk you through early access.