How to Add Enterprise SSO to Your AI App With Kinde: SAML, OIDC, and Beyond

Enterprise buyers will not deploy your AI app without SSO. Here is everything you need to know to pass that security review.

In this article, you will learn:

• Why enterprise SSO is now non-negotiable for AI apps that sell to businesses
• The difference between SAML and OIDC — and which one to use when
• How Kinde models enterprise connections with organizations
• How to configure a custom SAML connection in Kinde step by step
• How to configure a Microsoft Entra ID (Azure AD) SAML connection
• What home realm discovery is and why it makes the login experience seamless
• How JIT (just-in-time) provisioning works in Kinde
• How IdP-initiated SSO works (Kinde shipped this in February 2026)
• How to let enterprise customers configure their own SSO via the self-serve portal
• How to use Kinde's suspend organization feature when a customer churns or has a security incident

Let's dive in!

Why Enterprise SSO Is No Longer Optional for AI Apps

There is a question every AI founder building for enterprise customers will hear sooner or later, usually from IT security during a procurement review: "Do you support SSO?"

The wrong answer ends the deal. Not "we're working on it." Not "we have Google login." SSO — specifically SAML 2.0 or enterprise OIDC federated to the company's identity provider — is a hard requirement for any AI app that wants to handle company data at scale.

The reason is not bureaucracy. It is a genuine security need that AI tools make more acute than most SaaS products. When a 30-person team at a financial services firm deploys your AI app to analyze internal documents, every one of those 30 users needs to be automatically deprovisioned the moment they leave the company. With SSO, that happens instantly — their IdP account is deactivated and they cannot access your app, your AI's context, or your data. Without SSO, some offboarding ticket eventually gets filed and one of those users might still have access six weeks after their last day.

Enterprise IT teams also need your AI app to be visible in their identity governance stack. If your app lives outside their IdP's audit trail, it will not pass a SOC 2 or ISO 27001 review. SSO is what makes your app governable.

The good news: adding enterprise SSO no longer requires weeks of work. Kinde handles the SAML/OIDC infrastructure — you configure connections in a dashboard, your app code stays exactly as it is, and enterprise customers connect their Okta, Entra ID, or other IdP the same day they ask for it.

SAML vs OIDC: Choosing the Right Protocol

Before touching any configuration, understand which protocol your customer needs. Getting this wrong means starting over.

SAML 2.0 is the enterprise legacy standard. XML-based, widely supported by every major enterprise IdP including Okta, Microsoft Entra ID (Azure AD), Google Workspace, and Ping Identity. If your customer has been in business for more than 10 years or works in financial services, healthcare, or government, they almost certainly have SAML infrastructure. This is the protocol you will encounter most often in enterprise procurement reviews.

OIDC (OpenID Connect) is the modern standard, built on OAuth 2.0. JSON-based, simpler to implement, better suited for mobile and API-driven authentication. Increasingly preferred by newer enterprises and tech companies. If your customer uses Okta with OIDC configured, or runs a modern identity stack, OIDC is the cleaner choice.

Both are fully supported by Kinde. Here is a practical decision guide:

Note: If a customer sends you an XML metadata URL, they are using SAML. If they send you a discovery endpoint URL ending in .well-known/openid-configuration, they are using OIDC. The format of what they provide tells you the protocol.

How Kinde Models Enterprise SSO

Kinde's SSO model is built around two concepts you need to understand before configuring anything.

Kinde acts as the Service Provider (SP). Your enterprise customer acts as (or connects to) the Identity Provider (IdP). This means the IdP owns the user identities — their Okta, Entra ID, or Google Workspace is the source of truth. Kinde receives the authentication assertion from the IdP and issues its own session token to your app. Your application code always talks to Kinde — never directly to the customer's IdP.

Enterprise connections live on organizations. In Kinde, each enterprise customer is a Kinde organization. Their SSO connection is attached to that organization. This is the right model for multi-tenant AI apps: one connection per customer, each isolated, each independently configurable. Acme Corp's Okta SAML setup has no effect on Globex Inc's Entra ID configuration.

Step #1: Create an Organization for Your Enterprise Customer

Each enterprise customer gets their own Kinde organization. If you already have organizations set up, skip to Step #2.

Navigate to Organizations in your Kinde dashboard and select Create organization. Give it the name of the enterprise customer — this is internal to your Kinde account, not visible to end users. Note the org code assigned; you will use it when scoping the connection.

For multi-tenant AI apps, each customer organization is also where you will attach billing, custom roles, and per-org MFA requirements. The enterprise connection is just one of many things scoped per organization.

Step #2: Configure a Custom SAML Connection

This is the generic SAML path that works with any SAML 2.0-compliant IdP. Go through this if your customer uses an IdP not covered by Kinde's named integrations (Okta, Entra ID, Google Workspace, Cloudflare, LastPass).

In your Kinde dashboard, navigate to Settings → Environment → Authentication and scroll to the Enterprise connection section. Select Add connection.

Select Custom SAML and click Next. You will now configure the connection:

Step 2a: Connection name. Enter a descriptive name like Acme Corp Okta SAML. This is internal — use whatever helps you identify it.

Step 2b: Entity ID. Generate a random alphanumeric string, for example hEb876ZZlkg99Dwat64Mnbvyh129. Copy it — you will add this to your customer's IdP configuration as the SP Entity ID (also called Audience URI in some IdPs).

Step 2c: ACS URL. Kinde generates this for you. It is the URL where the IdP will send the SAML response after authentication. It looks like:

# Without custom domain
https://your-subdomain.kinde.com/login/saml/callback

# With custom domain
https://auth.yourdomain.com/login/saml/callback

Copy the ACS URL — your customer's IT team needs this to configure their IdP.

Step 2d: IdP metadata URL. Your customer's IT team provides this. It is a URL that Kinde fetches to get the IdP's public certificate and endpoints. In Okta it is typically https://your-okta-domain.okta.com/app/your-app-id/sso/saml/metadata. In other IdPs it may be called the Federation Metadata URL.

Step 2e: Email attribute. This tells Kinde which SAML attribute contains the user's email address. The standard value is http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress for Entra ID or simply email for most others. If left blank, Kinde defaults to email.

Step 2f: Home realm domains. Enter the email domains that route to this connection, for example acmecorp.com. When a user enters their email during login and it matches this domain, Kinde silently routes them to the Acme Corp SAML IdP without showing an SSO button. This is home realm discovery — users experience seamless, invisible SSO.

Step 2g: JIT provisioning. Enable Create a user record in Kinde if you want users to be automatically created in Kinde on their first SSO login. This is almost always the right choice for enterprise customers — it means you do not have to pre-provision users manually. They sign in through their IdP and Kinde creates their account automatically.

Step 2h: Trust email addresses. Enable this if you want Kinde to match SSO users to existing Kinde users by email. For example, if a user already has an account in Kinde via email/password, enabling this merges them with the incoming SSO identity. If disabled, a new separate identity is created regardless.

Select Save. The connection is created. Now give your customer's IT team the following information:

SP Entity ID (Audience URI): [your Entity ID string]
ACS URL (Reply URL):          https://your-subdomain.kinde.com/login/saml/callback
Name ID format:               Email address (urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress)

That is all the IT team needs to configure their IdP. Once they complete setup and activate the connection on their side, test by having a user from their domain attempt to log in to your app.

A working SAML connection in about 10 minutes of configuration on each side.

Step #3: Configure Microsoft Entra ID (Azure AD) SAML

Microsoft Entra ID is the most common enterprise IdP for AI apps selling into corporate accounts. Kinde has a dedicated Entra ID connection type that handles Entra-specific quirks — including a note that older Entra tenants require the Entity ID to have a spn: prefix.

Navigate to Settings → Authentication → Add connection → Microsoft Entra ID (SAML).

The configuration is similar to custom SAML with a few Entra-specific fields:

Step 3a: Connection name. For example Acme Corp Entra ID.

Step 3b: Entity ID. Generate a random string as before. If your connection fails after setup, try prefixing it with spn: — this is an older Entra ID requirement some tenants still have.

Step 3c: IdP metadata URL. From the Microsoft Entra admin center, navigate to Enterprise applications → your app → Single sign-on → SAML → App Federation Metadata URL. Copy this URL and paste it into Kinde.

Step 3d: Email attribute. For Entra ID SAML, the email attribute is:

http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress

Enter this value exactly. Getting this wrong is the most common cause of Entra ID SAML failures — Kinde receives the SAML assertion but cannot find the email claim.

Step 3e: Home realm domains. Enter the corporate domain(s), for example acmecorp.com, acmecorp.onmicrosoft.com.

On the Entra ID side, your customer's IT admin needs to create an Enterprise Application in the Azure portal with:

• Reply URL (ACS URL): The ACS URL from Kinde
• Identifier (Entity ID): The Entity ID string you created in Kinde
• Sign on URL: Your app's login URL (optional)
• Attributes & Claims: Ensure the email claim is mapped to the user's email attribute

Note: If you need additional Entra ID attributes in Kinde (like department, phone number, or group membership), you can sync them using a Kinde post-authentication workflow. The workflow reads the SAML assertion attributes and writes them to Kinde custom user properties.

Step #4: Enable IdP-Initiated SSO

Standard SAML flow is SP-initiated: the user starts at your app, clicks login, gets redirected to the IdP, authenticates, and comes back. This is the most common setup.

Kinde shipped IdP-initiated SSO in February 2026. With IdP-initiated flow, users start the login from their IdP portal — for example, clicking your app's tile in Okta or the Microsoft MyApps dashboard. They are authenticated at the IdP first, and Kinde handles the unsolicited SAML response when it arrives.

To enable IdP-initiated SSO for a connection, navigate to the connection in Kinde and toggle on Allow IdP-initiated SSO. When this is enabled, Kinde also uses the email from the SAML response to pre-fill the login screen if the user ends up being redirected back to an SP-initiated flow, reducing friction.

Enterprise customers who use a company intranet or application portal (like Okta's dashboard or Microsoft MyApps) often require IdP-initiated flow. Without it, they cannot tile your app in their portal — and tiling apps is how IT controls visibility and access across the company. Enabling this expands your deployment options inside enterprise accounts significantly.

Step #5: Set Up Home Realm Discovery for Seamless Login

Home realm discovery is what makes enterprise SSO feel invisible to end users. Instead of showing a generic "Sign in with SSO" button that users may not understand, Kinde detects the user's email domain and automatically routes them to the correct IdP.

You already set home realm domains in Step #2. Here is how the experience works once configured:

1. User navigates to your AI app and reaches the Kinde login page
2. User enters their email address: alice@acmecorp.com
3. Kinde matches the acmecorp.com domain to the Acme Corp SAML connection
4. Kinde silently redirects Alice to Acme Corp's Okta for authentication
5. Alice authenticates with Okta (likely already SSO'd from her device)
6. Okta sends the SAML assertion back to Kinde
7. Kinde issues a session token and Alice lands in your app

Steps 3 through 6 happen in under a second. From Alice's perspective, she typed her email and landed in the app. No separate SSO button. No understanding of SAML required.

Note: Home realm domains must be unique across all connections in your Kinde environment. If you add acmecorp.com to one connection, no other connection can also claim it.

Step #6: Let Enterprise Customers Configure Their Own SSO

For AI apps with many enterprise customers, having your team configure each SAML connection manually does not scale. Kinde supports self-serve SSO configuration (available on Scale plans) — enterprise customers can configure their own SSO connection through the Kinde self-serve portal.

When self-serve SSO is enabled for an organization, the customer's admin (a user with the appropriate role in your app) can visit the self-serve portal, navigate to Security or Connections, and configure their SAML or OIDC connection themselves.

They enter their IdP metadata URL, set their attribute mappings, and submit. Kinde validates the configuration and creates the connection. Your team gets notified but does not need to be involved in the data entry.

To enable this, navigate to Settings → Self-serve portal → and enable SSO self-management for the relevant organizations. You can control which organizations have this capability — you might enable it only for enterprise-tier customers.

This is the SSO motion that scales. Your enterprise sales team closes the deal and mentions SSO as a feature the customer can configure themselves on day one. No engineering ticket. No back-and-forth over Entity IDs. The customer's IT admin does the setup in your self-serve portal in 20 minutes.

Step #7: Read Enterprise Identity in Your App

Once enterprise SSO is configured, the user's Kinde session looks exactly the same as any other authenticated session. Your application code does not need to know or care whether the user authenticated via email OTP, Google login, or enterprise SAML. The same Kinde SDK methods work for all of them.

In a Next.js application:

// app/dashboard/page.tsx
import { getKindeServerSession } from "@kinde-oss/kinde-auth-nextjs/server";
import { redirect } from "next/navigation";

export default async function DashboardPage() {
  const { isAuthenticated, getUser, getOrganization } =
    getKindeServerSession();

  if (!(await isAuthenticated())) {
    redirect("/api/auth/login");
  }

  const user = await getUser();
  const org = await getOrganization();

  // user.email comes from the SAML assertion for SSO users
  // org.orgCode identifies which enterprise customer this is
  // No special handling needed for SSO vs non-SSO users

  return (
    <main className="p-8">
      <h1>Welcome, {user?.given_name}</h1>
      <p className="text-gray-500">
        Signed in via {org?.name ?? "your organization"}
      </p>
    </main>
  );
}

If you want to know which authentication method the user used (useful for audit logs or analytics), you can check the identities from the Kinde Management API. But for most application logic, you simply use getUser() and getOrganization() without worrying about the underlying auth method.

For AI apps that need to enforce that specific customers must use SSO and cannot fall back to email/password, configure an org-level access policy in Kinde. Navigate to Organizations → select the org → Access policies → enable Require enterprise connection. Users who try to log in to this organization via email/password will be blocked and prompted to use SSO instead.

// Verify the user is authenticated via enterprise SSO for sensitive AI operations
// This is an optional extra layer — Kinde's access policies handle the enforcement,
// but you can also check in your API routes for audit purposes
import { getKindeServerSession } from "@kinde-oss/kinde-auth-nextjs/server";
import { NextRequest, NextResponse } from "next/server";

export async function POST(request: NextRequest) {
  const { isAuthenticated, getOrganization } = getKindeServerSession();

  if (!(await isAuthenticated())) {
    return NextResponse.json({ error: "Unauthenticated" }, { status: 401 });
  }

  const org = await getOrganization();

  // Log the org for audit trail — critical for enterprise AI compliance
  console.log(`AI request from org: ${org?.orgCode}, user: ${(await getKindeServerSession().getUser())?.id}`);

  // Execute AI operation
  // ...

  return NextResponse.json({ result: "..." });
}

Step #8: Suspend an Organization Instantly

Enterprise contracts end. Security incidents happen. When either occurs, you need to cut off an entire organization's access immediately — not one user at a time.

Kinde added organization suspension in February 2026. When you suspend an org, every active token is revoked and every session is invalidated instantly. No user from that organization can log in to your app, regardless of how they authenticated.

Navigate to Organizations → select the org → Settings → Suspend organization. Select Suspend. Done.

Unsuspending restores access just as quickly — toggle the same setting off and all users can log back in at their next login attempt.

This feature is essential for enterprise AI apps for two reasons. First, when a customer churns or does not renew, you need access revocation to happen immediately, not when individual users try to log in and find their tokens expired. Second, if a customer reports a security incident (a compromised account, suspicious AI queries, a potential data breach), suspension gives you a one-click kill switch while you investigate.

Putting It All Together

Here is the full enterprise SSO setup checklist for your AI app:

In Kinde dashboard:

• Organization created for each enterprise customer
• SAML or OIDC connection configured and saved
• Home realm domain(s) set for seamless routing
• JIT provisioning enabled for automatic user creation
• IdP-initiated SSO enabled (if customer uses an app portal)
• Org-level access policy set to require enterprise connection (optional but recommended for security-sensitive customers)
• Self-serve SSO enabled for enterprise-tier orgs (Scale plan)

What you give the customer's IT team:

• SP Entity ID (Audience URI)
• ACS URL (Reply URL)
• Name ID format: urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress

What the customer's IT team gives you:

• IdP metadata URL (or the XML metadata itself)
• Email attribute name (if non-standard)
• Home realm domains to register

In your application code:

• No changes required to authentication logic
• Use getUser() and getOrganization() as normal
• Add org-level access policy enforcement in API routes if needed
• Log orgCode in audit trails for all AI operations

SAML Troubleshooting Reference

These are the most common SAML configuration problems and how to fix them in Kinde:

Navigate to Settings → Logs → Authentication logs in Kinde to see detailed SAML assertion logs for failed authentication attempts. This is the fastest way to identify configuration issues.

Conclusion

In this article, you configured enterprise SSO for your AI app — custom SAML, Microsoft Entra ID SAML, home realm discovery, JIT provisioning, IdP-initiated flow, customer self-serve setup, and organization suspension. Your AI app can now pass enterprise security reviews, integrate with any major corporate identity provider, and automatically revoke access when users leave a customer's organization.

The entire configuration lives in Kinde. Your application code is completely unchanged — the same getUser() and getOrganization() calls that work for email login work for enterprise SAML. Kinde normalizes all authentication methods into the same session model.

Enterprise SSO used to be the feature that required a dedicated engineering sprint and an enterprise-tier contract with your auth provider. With Kinde, it is a configuration that takes an afternoon and is available on all paid plans.

Create a free Kinde account at kinde.com — 10,500 monthly active users, no credit card required — and have your first enterprise connection configured before your next security review.