Merge pull request #474 from kinde-oss/Fix/Docs-mixed-minor-changes

Fix/docs mixed minor changes - Alex review

Author: clairekinde11

src/content/docs/authenticate/auth-guides/enterprise-connections-identity.mdx

@@ -0,0 +1,63 @@
+---
+page_id: 10b52ab6-95e4-47ab-be62-b1c7f7cfcddd
+title: Guide to enterprise auth and user identities
+sidebar:
+  order: 3
+relatedArticles:
+  - fcf28a71-c3a8-4474-9564-ad089d3f2105
+  - e519f56a-603a-44dd-a946-3aaf6fb256ce
+---
+
+At Kinde, each user can only have one enterprise identity provider (IdP) connection as part of their user profile. This is because we want to keep things simple, secure, and reliable.
+
+We get asked about this regularly, so this document explains our reasoning from a security and architectural perspective.
+
+## What is an enterprise connection?
+
+An enterprise connection allows users to sign in to your product using their organization’s identity provider — such as Okta, Azure AD, or Google Workspace. This enables Single Sign-On (SSO), centralized user management, and improved security for enterprise customers.
+
+## Why only one identity per user?
+
+Many customer identity platforms, including Kinde, enforce a one-to-one relationship between a user and an enterprise connection. Here’s why:
+
+### 1. Prevents identity conflicts
+
+If a user could sign in through multiple enterprise providers, it becomes difficult to determine whether those identities belong to the same person. This can result in:
+
+- Duplicate accounts for the same user
+- Conflicting user attributes (email, name, roles, etc.)
+- Confusion around permissions and organization membership
+
+Restricting to a single enterprise connection ensures a consistent and predictable identity model.
+
+### 2. Security and account Integrity
+
+Allowing multiple enterprise connections introduces significant security risks:
+
+- **Risk of account hijacking:** If a user can link multiple IdPs, and identity claims like email or subject ID (`sub`) overlap or are not verified consistently, it becomes possible for unauthorized users to gain access to another user’s account.
+- **Inconsistent identity claims:** Different IdPs use different formats and identifiers. One provider may use an email address, another a unique internal ID. Reconciling these automatically increases the risk of incorrect mappings and privilege escalation.
+- **Reduced auditability:** Security audits and access logs rely on a single, traceable identity. If a user can authenticate through multiple IdPs, it becomes harder to guarantee that all actions are traceable to a single, verified identity.
+- **Clear accountability:** With one connection per user, the responsibility for identity management, password resets, session revocation, and breach response remains clearly with the source identity provider.
+
+### 3. Simplified tenant and access management
+
+In multi-tenant applications, each enterprise typically has its own workspace or organization. Supporting one IdP per user:
+
+- Keeps tenant boundaries clean
+- Prevents role or permission leakage between organizations
+- Simplifies access control logic
+
+## What if someone needs access to multiple organizations?
+
+We support users belonging to multiple organizations within Kinde. In edge cases (such as contractors working across companies) we recommend adding [enterprise connections at the organization level](/authenticate/enterprise-connections/enterprise-connections-b2b/). This means the user signs in directly to the relevant organization, with no confusion about where to be routed. This feature is only available on the Kinde Scale plan.
+
+If you are not on the relevant plan, other ways to handle this include:
+
+- Use separate emails for each organization
+- Use different auth methods per organization
+
+## Built for security, designed for clarity
+
+This choice to allow only one enterprise identity per user aligns with industry best practices and helps keep your users, data, and systems secure. By enforcing this, Kinde provides a stable and trusted identity layer you can build on with confidence. 
+
+If you have any questions about more advanced SSO or identity configurations, [contact our team](https://kinde.com/contact). We’re happy to help.

src/content/docs/authenticate/enterprise-connections/provision-users-enterprise.mdx

@@ -53,6 +53,8 @@ This method of provisioning requires you to add the enterprise connection as par
 
 Post identity details to this endpoint `POST /api/v1/users/{user_id}/identities` with `enterprise` as the type and the `connection_id`. For more information, see [Create identity](https://docs.kinde.com/kinde-apis/management/#tag/users/post/api/v1/users/{user_id}/identities).
 
+You can search connections via API and filter them by domain. This can help you obtain the connection ID.
+
 **Add the enterprise connection identity manually**
 
 1. Open a user’s profile and select **Add identity**.

src/content/docs/authenticate/multi-factor-auth/about-multi-factor-authentication.mdx

@@ -18,6 +18,8 @@ app_context:
 
 To increase security for your product, you can enable multi-factor authentication (MFA). This means that your users sign in using at least two authentication methods, for example, password _plus_ verification code.
 
+If you don't want to apply MFA settings for all users, you can set [MFA per organization](/authenticate/multi-factor-auth/mfa-per-org/) if you're on the Kinde Scale plan.
+
 ## **Available MFA factors**
 
 Kinde supports the following secondary factors for MFA.

src/content/docs/authenticate/multi-factor-auth/mfa-per-org.mdx

@@ -41,6 +41,8 @@ In Kinde, go to **Settings > Environment > Multi-factor auth**.
 
 - Select **Yes** or **Optional** - If you want everyone, in every organization to use MFA’. Note that if you select **Yes** here, MFA will apply in all organizations regardless of what you set at the organization level.
 
+Whatever you select here, you can still exempt roles from MFA per organization.
+
 ## Switch on MFA for an organization
 
 MFA methods selected here will replace those selected at the environment level.

src/content/docs/design/content-customization/update-auth-page-content.mdx

@@ -40,9 +40,9 @@ Variables can be used on pages as follows.
 
 **Sign in confirm code page**
 
-`${email_address}`
+`${email_address}` - shows the full email address of the user
 
-`${email_address_obfuscated}`
+`${email_address_obfuscated}` - shows only a part of the user's email
 
 **Sign up confirm code page**