Merge branch 'alexcarpenter/sdki-747-launch-draft-docs-changes' into …

…alexcarpenter/combined-flow-remix

CONTRIBUTING.md

@@ -575,7 +575,7 @@ The `<TutorialHero />` component is used at the beginning of a tutorial-type con
 
 - Install `@clerk/nextjs`
 - Set up your environment keys to test your app locally
-- Add `<ClerkProvider />` to your application
+- Add `<ClerkProvider>` to your application
 - Use Clerk middleware to implement route-specific authentication
 - Create a header with Clerk components for users to sign in and out
 

docs/_partials/react-hooks.mdx

@@ -0,0 +1,9 @@
+- [`useUser()`](/docs/references/react/use-user){{ target: '_blank' }}
+- [`useClerk()`](/docs/references/react/use-clerk){{ target: '_blank' }}
+- [`useAuth()`](/docs/references/react/use-auth){{ target: '_blank' }}
+- [`useSignIn()`](/docs/references/react/use-sign-in){{ target: '_blank' }}
+- [`useSignUp()`](/docs/references/react/use-sign-up){{ target: '_blank' }}
+- [`useSession()`](/docs/references/react/use-session){{ target: '_blank' }}
+- [`useSessionList()`](/docs/references/react/use-session-list){{ target: '_blank' }}
+- [`useOrganization()`](/docs/references/react/use-organization){{ target: '_blank' }}
+- [`useOrganizationList()`](/docs/references/react/use-organization-list){{ target: '_blank' }}

docs/advanced-usage/satellite-domains.mdx

@@ -115,7 +115,7 @@ To access authentication state from a satellite domain, users will be transparen
           # CLERK_SIGN_UP_URL=http://localhost:3000/sign-up
           ```
         </CodeBlockTabs>
-      - You will also need to add the `allowedRedirectOrigins` property to `<ClerkProvider />` on your _primary domain app_ to ensure that the redirect back from primary to satellite domain works correctly. For example:
+      - You will also need to add the `allowedRedirectOrigins` property to `<ClerkProvider>` on your _primary domain app_ to ensure that the redirect back from primary to satellite domain works correctly. For example:
 
         <CodeBlockTabs options={["Development", "Production"]}>
           ```tsx {{ filename: 'app/layout.tsx' }}

docs/authentication/configuration/sign-up-sign-in-options.mdx

@@ -17,7 +17,7 @@ Identifiers are how your application recognizes an individual user. There are th
 
 In the application configuration screen, you can select multiple identifiers, but at least one is required.
 
-**Email address** is the most common primary identifier. During the sign-up process, a user must supply and verify their email address. They must keep an email address on their account at all times. However, the email address that was used for registration can be later changed from the user's profile page.
+**Email address** is the most common primary identifier. When it is the only enabled identifier, users are required to supply an email address during sign-up and keep one on their account at all times. The email address that was supplied during sign-up can be later changed from the user's profile page.
 
 When **phone number** is selected as the identifier, a user can sign up with their phone number and receive a code via SMS to verify it. SMS functionality is restricted to phone numbers from countries enabled on your [SMS allowlist](#sms-allowlist).
 
@@ -162,12 +162,12 @@ To enable social connections:
 
 ## Web3 authentication
 
-Clerk provides [Web3 authentication](/docs/users/web3) with either MetaMask or Coinbase Wallet. As part of validating the accuracy of the returned Web3 account address, Clerk handles the signing of a message and verifying the signature. Because sign-in with Web3 uses the same abstraction as our other authentication factors, like passwords or email links, other Clerk features like multi-factor authentication and profile enrichment work for Web3 users out-of-the-box.
+Clerk provides [Web3 authentication](/docs/users/web3) with either MetaMask, Coinbase Wallet or OKX Wallet. As part of validating the accuracy of the returned Web3 account address, Clerk handles the signing of a message and verifying the signature. Because sign-in with Web3 uses the same abstraction as our other authentication factors, like passwords or email links, other Clerk features like multi-factor authentication and profile enrichment work for Web3 users out-of-the-box.
 
 To enable Web3 authentication:
 
 1. In the Clerk Dashboard, navigate to the [**Web3**](https://dashboard.clerk.com/last-active?path=user-authentication/web3) page.
-1. Toggle on the Web3 provider. Currently, Clerk supports MetaMask and Coinbase Wallet.
+1. Enable your preferred Web3 provider.
 
 ## Multi-factor authentication
 

docs/authentication/enterprise-connections/easie/microsoft.mdx

@@ -74,7 +74,7 @@ To make the setup process easier, it's recommended to keep two browser tabs open
 
   [nOAuth](https://www.descope.com/blog/post/noauth) is an exploit in Microsoft Entra ID OAuth apps that can lead to account takeovers via email address spoofing. Clerk mitigates this risk by enforcing stricter checks on verified email addresses.
 
-  For further security, Microsoft offers an optional `xms_edov` claim, which provides additional context to determine whether the returned email is verified.
+  For further security, Microsoft offers an optional `xms_edov` [claim](https://learn.microsoft.com/en-us/entra/identity-platform/optional-claims-reference), which provides additional context to determine whether the returned email is verified.
 
   This claim is mandatory for applications backing EASIE connections. To enable it, you must:
 
@@ -83,8 +83,6 @@ To make the setup process easier, it's recommended to keep two browser tabs open
   1. Select **Add optional claim**.
   1. For the **Token type**, select **ID**. Then, in the table that opens, enable the `email` and `xms_pdl` claims.
   1. At the bottom of the modal, select **Add**. A new modal will prompt you to turn on the Microsoft Graph email permission. Enable it, then select **Add** to complete the form.
-     > [!NOTE]
-     > At the time of writing, the `xms_edov` claim is still in preview and may not be available for all apps. We'll choose another claim and rename it in the manifest later.
   1. Repeat the previous steps for **Token type**, but select **Access** instead of **ID**. The **Optional claims** list should now show two claims for `email` and two for `xms_pdl`: one each for **ID** and **Access**.
   1. In the sidebar, go to **Manifest**.
   1. In the text editor, search for `"acceptMappedClaims"` and set its value from `null` to `true`.

docs/authentication/enterprise-connections/oidc/custom-provider.mdx

@@ -0,0 +1,88 @@
+---
+title: Add a custom OpenID Connect (OIDC) Provider as an enterprise connection
+description: Learn how to integrate a custom OIDC provider with Clerk for Enterprise SSO.
+---
+
+<TutorialHero
+  beforeYouStart={[
+    {
+      title: "Add the Enhanced Authentication add-on to your Pro plan",
+      link: "/pricing",
+      icon: "plus-circle",
+    },
+    {
+      title: "Enable email address as an identifier for your app",
+      link: "/docs/authentication/configuration/sign-up-sign-in-options#identifiers",
+      icon: "key",
+    },
+  ]}
+>
+  - Add a custom OIDC provider to authenticate users with Enterprise SSO
+</TutorialHero>
+
+This guide explains how to use a custom [OpenID Connect (OIDC)](https://openid.net/developers/how-connect-works) provider to authenticate users via Enterprise SSO.
+
+To make the setup process easier, it's recommended to keep two browser tabs open: one for the [Clerk Dashboard](https://dashboard.clerk.com/last-active?path=user-authentication/sso-connections) and one for your Identity Provider (IdP).
+
+<Steps>
+  ### Set up an enterprise connection in Clerk
+
+  1. In the Clerk Dashboard, navigate to the [**SSO Connections**](https://dashboard.clerk.com/last-active?path=user-authentication/sso-connections) page.
+  1. Select **Add connection** and select **For specific domains**.
+  1. Under **Third party**, select **OpenID Connect (OIDC)**.
+  1. Add the **Name** of the connection.
+  1. Add the **Key** of the provider. This is the provider's unique identifier (cannot be changed after creation).
+  1. Add the **Specific Domain** that you want to allow this connection for. This is the domain of the users you want to allow to sign in to your app.
+  1. Select **Add connection**. You will be redirected to the connection's configuration page. Keep this page open.
+
+  ### Configure your IdP
+
+  1. If necessary, create a new application in your IdP.
+  1. In the connection's configuration page of the Clerk Dashboard, copy the **Authorized redirect URI**.
+  1. Add the value to your IdP's whitelisted URLs.
+  1. Find your application's **Discovery Endpoint**, **Client ID**, and **Client Secret** and copy them.
+
+  ### Set the Discovery Endpoint, Client ID, and Client Secret in Clerk
+
+  1. In your IdP settings, copy your application's **Discovery Endpoint**, **Client ID**, and **Client Secret**.
+  1. In the connection's configuration page in the Clerk Dashboard, paste these values in their respective fields.
+  1. Under **Scopes**, add the minimum required scopes based on the IdP's documentation if needed. Common OIDC scopes include `openid`, `email`, and `profile`.
+  1. Select **Save**.
+
+  > [!NOTE]
+  > Most IdPs provide a **Discovery Endpoint** to retrieve metadata about an OIDC provider. If your IdP doesn't offer this endpoint or if you need greater control over the setup process, in the connection's configuration page in the Clerk Dashboard, find the **Identity Provider Configuration** section and select **Use Manual Configuration** to manually configure the connection.
+
+  ### Configure attribute mapping (optional)
+
+  Clerk expects the claims returned by your IdP to follow the [OIDC Standard](https://openid.net/specs/openid-connect-core-1_0.html#StandardClaims). If your provider returns claims in a non-standard format, use the **Attribute Mapping** section on the connection's configuration page to adjust the mapping of Clerk's user properties to match the IdP's claim attributes.
+
+  > [!WARNING]
+  > OIDC Enterprise connections require the [`email_verified`](https://openid.net/specs/openid-connect-core-1_0.html#StandardClaims:~:text=Section%C2%A05.7.-,email_verified,-boolean) claim to verify email ownership. However, some IdPs, such as Microsoft Azure Active Directory, might not return this claim or use a non-standard format.
+  >
+  > If the IdP doesn't return this claim, you can leave the **Email address verified** field blank and set the **Default value** to **True**. This should only be done if you fully trust the IdP, as it can expose your app to [OAuth attacks](https://www.descope.com/blog/post/noauth).
+
+  ### Allow additional identifiers (optional)
+
+  User profile information is sourced from the IdP. To allow users to add new identifiers (e.g., email address or phone number) to their profiles:
+
+  1. In the connection's configuration page of the Clerk Dashboard, navigate to the **Advanced** tab.
+  1. Enable **Allow additional identifiers**.
+  1. Select **Save**.
+
+  ### Enable the connection for Clerk
+
+  To make the connection available for your users to authenticate with:
+
+  1. Navigate back to the Clerk Dashboard where you should still have the connection's configuration page open. If not, navigate to the [**SSO connections**](https://dashboard.clerk.com/last-active?path=user-authentication/sso-connections) page and select the connection.
+  1. At the top of the page, toggle on **Enable connection** and select **Save**.
+
+  ### Test your connection
+
+  The simplest way to test your enterprise connection is to visit your Clerk app's [Account Portal](/docs/customization/account-portal/overview), which is available for all Clerk apps out-of-the-box.
+
+  1. In the Clerk Dashboard, navigate to the [**Account Portal**](https://dashboard.clerk.com/last-active?path=account-portal) page.
+  1. Next to the **Sign-in** URL, select **Visit**. The URL should resemble:
+     - **For development** – `https://your-domain.accounts.dev/sign-in`
+     - **For production** – `https://accounts.your-domain.com/sign-in`
+  1. Sign in with your IdP account.
+</Steps>

docs/authentication/enterprise-connections/overview.mdx

@@ -1,15 +1,15 @@
 ---
-title: Enterprise SSO
+title: Enterprise Single Sign-On (SSO)
 description: Clerk provides Enterprise SSO to authenticate users via federated Identity Providers such such as Azure AD, Okta, Google Workspace and more.
 ---
 
-With Enterprise SSO, users can sign in seamlessly using their Identity Provider's (IdP) credentials and have their user data synchronized with Clerk. You can learn more about the process in the guides on [authentication flows](/docs/authentication/enterprise-connections/authentication-flows) and [account linking](/docs/authentication/enterprise-connections/account-linking).
+Enterprise Single Sign-On (SSO) allows users to sign in seamlessly using their Identity Provider (IdP) credentials (e.g.,Azure AD, Okta, or Google Workspace) and have their user data synchronized with Clerk. Clerk supports multiple protocols for implementing Enterprise SSO, including SAML and OIDC. Learn more about the process in the guides on [authentication flows](/docs/authentication/enterprise-connections/authentication-flows) and [account linking](/docs/authentication/enterprise-connections/account-linking).
 
 ## SAML
 
 Clerk supports Enterprise SSO via the SAML protocol, enabling you to create authentication strategies for an IdP. The following IdPs are supported: [Microsoft Azure AD](/docs/authentication/enterprise-connections/saml/azure), [Google Workspace](/docs/authentication/enterprise-connections/saml/google), and [Okta Workforce](/docs/authentication/enterprise-connections/saml/okta). However, you can also [integrate with any other IdP](/docs/authentication/enterprise-connections/saml/custom-provider) that supports the SAML protocol.
 
-### Allow subdomains
+#### Allow subdomains
 
 Authenticating via SAML SSO requires the user's email address domain to match the exact domain the SAML connection has been configured with. By default, subdomains are not supported. For example, a user with the email address `[email protected]` wouldn't be able to use a SAML connection with the `example.com` domain to authenticate.
 
@@ -24,7 +24,11 @@ To configure subdomains for a SAML connection:
 > [!NOTE]
 > To enable the **Allow subdomains** option, your SAML connection domain must be an [eTLD+1](https://developer.mozilla.org/en-US/docs/Glossary/eTLD).
 
-## EASIE
+## OIDC
+
+Clerk supports Enterprise SSO via the OpenID Connect (OIDC) protocol, either through [EASIE](#easie) or by [integrating with any OIDC-compatible provider](/docs/authentication/enterprise-connections/oidc/custom-provider).
+
+### EASIE
 
 [EASIE](https://easie.dev) SSO is a way for applications to provide enterprise-grade SSO through a multi-tenant OpenID provider. It is designed to be an easier alternative to SAML SSO.
 
@@ -33,15 +37,15 @@ The following IdPs are supported: Google Workspace and Microsoft Entra ID. For _
 - [Google](/docs/authentication/social-connections/google)
 - [Microsoft](/docs/authentication/social-connections/microsoft)
 
-### Automatic deprovisioning
+#### Automatic deprovisioning
 
 Clerk prevents users linked to deprovisioned accounts in the OpenID provider from accessing the app.
 
 Within 10 minutes of a user being removed from the OpenID provider (e.g. [suspendeded](https://support.google.com/a/answer/33312?hl=en) or [deleted](https://support.google.com/a/answer/33314?hl=en) via Google Workspace, or [deleted](https://learn.microsoft.com/en-us/entra/fundamentals/how-to-create-delete-users#delete-a-user) via Microsoft Entra), Clerk will recognize that the user has been deprovisioned and will revoke that user's existing sessions.
 
 It is ultimately the app's responsibility to handle this unauthenticated state and display something appropriate to the user. For example, Next.js apps using [`auth.protect()`](/docs/references/nextjs/auth#auth-protect) will automatically redirect the user to the sign-in page.
 
-## SAML vs. EASIE
+### SAML vs. EASIE
 
 The primary security difference between EASIE SSO and SAML SSO is that EASIE depends on a multi-tenant identity provider, while SAML depends on a single-tenant identity provider. Relying on a multi-tenant provider **increases** the risk that a user from one tenant will mistakenly be granted access to the resources of another tenant. While Clerk implements [measures to address this risk](https://easie.dev/#mitigating-tenant-crossover-vulnerabilities), apps that require single-tenant IdPs should opt for SAML.
 

docs/backend-requests/making/custom-session-token.mdx

@@ -40,11 +40,11 @@ This guide will show you how to customize a session token to include additional
     export default async function Page() {
       const { sessionClaims } = await auth()
 
-      const firstName = sessionClaims?.fullName
+      const fullName = sessionClaims?.fullName
 
       const primaryEmail = sessionClaims?.primaryEmail
 
-      return NextResponse.json({ firstName, primaryEmail })
+      return NextResponse.json({ fullName, primaryEmail })
     }
     ```
 
@@ -55,11 +55,11 @@ This guide will show you how to customize a session token to include additional
     export default async function handler(req: NextApiRequest, res: NextApiResponse) {
       const { sessionClaims } = getAuth(req)
 
-      const firstName = sessionClaims.fullName
+      const fullName = sessionClaims.fullName
 
       const primaryEmail = sessionClaims.primaryEmail
 
-      return res.status(200).json({ firstName, primaryEmail })
+      return res.status(200).json({ fullName, primaryEmail })
     }
     ```
   </CodeBlockTabs>
@@ -73,14 +73,14 @@ This guide will show you how to customize a session token to include additional
   1. Create the `CustomJwtSessionClaims` interface and declare it globally.
   1. Add the custom claims to the `CustomJwtSessionClaims` interface.
 
-  The following example demonstrates how to add the `firstName` and `primaryEmail` claims to the `CustomJwtSessionClaims` interface.
+  The following example demonstrates how to add the `fullName` and `primaryEmail` claims to the `CustomJwtSessionClaims` interface.
 
   ```tsx {{ filename: 'types/globals.d.ts' }}
   export {}
 
   declare global {
     interface CustomJwtSessionClaims {
-      firstName?: string
+      fullName?: string
       primaryEmail?: string
     }
   }

docs/backend-requests/making/jwt-templates.mdx

@@ -10,8 +10,6 @@ Clerk offers the ability to generate [JSON Web Tokens](https://en.wikipedia.org/
 
 You can control the claims that will go into these tokens by creating custom **JWT templates** that fit your needs. This enables you to integrate with any third-party services that support authentication with JWTs. An example use case is integrating with a third-party service that is able to consume JWTs, but requires them to be in a particular format.
 
-<Include src="_partials/token-size-callout" />
-
 ## What is a JWT template?
 
 **JWT templates** are essentially JSON objects that specify claims to be included in the generated tokens, along with their respective values.