@workos/mcp-docs-server 0.1.0 → 0.2.0

package/.docs/organized/docs/{user-management → authkit}/index.mdx

@@ -1,36 +1,34 @@
 ---
-title: User Management
+title: AuthKit
 description: >-
-  Easy to use authentication APIs designed to provide a flexible, secure, and
-  fast integration.
+  Easy to use authentication platform designed to provide a flexible, secure,
+  and fast integration.
 showNextPage: true
-originalPath: .tmp-workos-clone/packages/docs/content/user-management/index.mdx
+originalPath: .tmp-workos-clone/packages/docs/content/authkit/index.mdx
 ---
 
+<WorkOSCliCallout />
+
 ## Introduction {{ "visibility": "no-quick-nav" }}
 
-Integrating User Management features into your app is quick and easy. In this guide, we’ll walk you through adding a hosted authentication flow to your application using [AuthKit](/user-management/authkit).
+Integrating AuthKit into your app can be done in less than ten minutes. In this guide, we'll walk you through adding a hosted authentication flow to your application using AuthKit.
+
+> **Want to skip the manual setup?** The [CLI Installer](/authkit/cli-installer) detects your framework, installs the SDK, configures your dashboard, and writes the integration code — all with a single command.
 
-In addition to this guide, there are a variety of [example apps](/user-management/example-apps) available to help with your integration.
+In addition to this guide, there are a variety of [example apps](/authkit/example-apps) available to help with your integration.
 
 ## Before getting started {{ "visibility": "no-quick-nav" }}
 
-To get the most out of this guide, you’ll need:
+To get the most out of this guide, you'll need:
 
 - A [WorkOS account](https://dashboard.workos.com/)
 - Your WorkOS [API Key](/glossary/api-key) and [Client ID](/glossary/client-id)
 
-Additionally you'll need to activate User Management in your WorkOS Dashboard if you haven't already. In the _Overview_ section, click the _Set up User Management_ button and follow the instructions.
-
-![WorkOS dashboard with the User Management setup button highlighted](https://images.workoscdn.com/images/01c528be-f3ed-416d-b1c4-9f8cf923d138.png?auto=format&fit=clip&q=50)
-
 ---
 
 ## (1) Configure your project
 
-Let’s add the necessary dependencies and configuration in your WorkOS Dashboard.
-
-<StackSelection />
+Let's add the necessary dependencies and configuration in your WorkOS Dashboard.
 
 ### Install dependencies
 
@@ -66,6 +64,12 @@ Let’s add the necessary dependencies and configuration in your WorkOS Dashboar
   npm install @workos-inc/node
   ```
 
+  For CSRF protection on state-changing routes like logout, also install `csrf-csrf`:
+
+  ```bash title="Install CSRF protection"
+  npm install csrf-csrf cookie-parser
+  ```
+
 - $ backend="ruby"
   First, install the WorkOS gem.
 
@@ -73,6 +77,12 @@ Let’s add the necessary dependencies and configuration in your WorkOS Dashboar
   gem install workos
   ```
 
+  For CSRF protection on state-changing routes like logout, also install `rack-csrf`:
+
+  ```bash title="Install CSRF protection"
+  gem install rack_csrf
+  ```
+
 - $ backend="python"
 
   First, install the Python SDK.
@@ -81,45 +91,53 @@ Let’s add the necessary dependencies and configuration in your WorkOS Dashboar
   pip install workos
   ```
 
+  For CSRF protection on state-changing routes like logout, also install `Flask-WTF`:
+
+  ```bash title="Install CSRF protection"
+  pip install Flask-WTF
+  ```
+
 ### Configure a redirect URI
 
-A redirect URI is a callback endpoint that WorkOS will redirect to after a user has authenticated. This endpoint will exchange the authorization code returned by WorkOS for an authenticated [User object](/reference/user-management/user). We’ll create this endpoint in the next step.
+A redirect URI is a callback endpoint that WorkOS will redirect to after a user has authenticated. This endpoint will exchange the authorization code returned by WorkOS for an authenticated [User object](/reference/authkit/user). We'll create this endpoint in the next step.
 
-You can set a redirect URI in the _Redirects_ section of the [WorkOS Dashboard](https://dashboard.workos.com). While [wildcards](/sso/redirect-uris/wildcard-characters) in your URIs can be used in the staging environment, they and query parameters cannot be used in production.
+You can set a redirect URI in the **Redirects** section of the [WorkOS Dashboard](https://dashboard.workos.com). We recommend using `http://localhost:3000/callback` as the default here.
+
+WorkOS supports using wildcard characters in Redirect URIs, but not for the default Redirect URI. More information about wildcard characters support can be found in the [Redirect URIs](/sso/redirect-uris/wildcard-characters) guide.
 
 - $ frontend="client-only"
 
-  ![Dashboard redirect URI](https://images.workoscdn.com/images/1ca70f77-a7d1-4320-aa24-732dc77e89de.png?auto=format&fit=clip&q=50)
+  ![Dashboard Redirect URIs](https://images.workoscdn.com/images/a7525cf3-ae4e-4dcd-91dd-27965b005472.png?auto=format&fit=clip&q=80)
 
   > For the client-only integration, make sure to set the callback URI as the same route where you require auth.
 
 - $ frontend="nextjs, remix, vanilla, react"
 
-  ![Dashboard redirect URI](https://images.workoscdn.com/images/58232e3c-ab9f-41cc-99f4-1692214073fa.png?auto=format&fit=clip&q=80)
+  ![Dashboard redirect URI](https://images.workoscdn.com/images/a7525cf3-ae4e-4dcd-91dd-27965b005472.png?auto=format&fit=clip&q=80)
 
-When users sign out of their application, they will be redirected to your app's [Logout redirect](/user-management/sessions/configuring-sessions/logout-redirect) location which is configured in the same dashboard area.
+When users sign out of their application, they will be redirected to your app's [Sign-out redirect](/authkit/sessions/configuring-sessions/sign-out-redirect) location which is configured in the same dashboard area.
 
-### Configure initiate login URL
+### Configure sign-in endpoint
 
 - $ frontend="client-only"
 
-  All login requests must originate at your application for the [PKCE](/reference/user-management/authentication/get-authorization-url/pkce) code exchange to work properly. In some instances, requests may not begin at your app. For example, some users might bookmark the hosted login page or they might be led directly to the hosted login page when clicking on a password reset link in an email.
+  All sign-in requests must originate at your application for the [PKCE](/reference/authkit/authentication/get-authorization-url/pkce) code exchange to work properly. In some instances, requests may not begin at your app. For example, some users might bookmark the hosted sign-in page or they might be led directly to the hosted sign-in page when clicking on a password reset link in an email.
 
 - $ frontend="nextjs, remix, vanilla, react"
 
-  Login requests should originate from your application. In some instances, requests may not begin at your app. For example, some users might bookmark the hosted login page or they might be led directly to the hosted login page when clicking on a password reset link in an email.
+  Sign-in requests should originate from your application. In some instances, requests may not begin at your app. For example, some users might bookmark the hosted sign-in page or they might be led directly to the hosted sign-in page when clicking on a password reset link in an email.
 
-In these cases, AuthKit will detect when a login request did not originate at your application and redirect to your application’s login endpoint. This is an endpoint that you define at your application that redirects users to sign in using AuthKit. We’ll create this endpoint in the next step.
+In these cases, AuthKit will detect when a sign-in request did not originate at your application and redirect to your application's sign-in endpoint. This is an endpoint that you define at your application that redirects users to sign in using AuthKit. We'll create this endpoint in the next step.
 
-You can configure the initiate login URL from the _Redirects_ section of the WorkOS dashboard.
+You can configure the sign-in endpoint from the **Redirects** section of the WorkOS dashboard.
 
-![Initiate login URL](https://images.workoscdn.com/images/ab7099e9-5577-4c53-afdb-e601f1e920ad.png?auto=format&fit=clip&q=50)
+![Sign-in endpoint](https://images.workoscdn.com/images/25b53ea7-95ba-48cc-b6e7-ccd1b1bc35eb.png?auto=format&fit=clip&q=80)
 
 - $ frontend="client-only"
 
   ### Configure CORS
 
-  Since your user's browser will be making calls to the WorkOS API directly, it is necessary to add your domain to the allow list in your WorkOS Settings. This can be configured in the _Configure CORS_ dialog on the _Authentication_ page of the WorkOS dashboard.
+  Since your user's browser will be making calls to the WorkOS API directly, it is necessary to add your domain to the allow list in your WorkOS Settings. This can be configured in the **Configure CORS** dialog on the **Authentication** page of the WorkOS dashboard.
 
   ![Screenshot of the WorkOS dashboard showing the "Configure CORS" option in the "Authentication" section.](https://images.workoscdn.com/images/3b7863df-8c59-4d48-ab91-f537fd5c9f66.png?auto=format&fit=clip&q=50)
 
@@ -144,7 +162,7 @@ You can configure the initiate login URL from the _Redirects_ section of the Wor
   NEXT_PUBLIC_WORKOS_REDIRECT_URI="http://localhost:3000/callback"
   ```
 
-  The `NEXT_PUBLIC_WORKOS_REDIRECT_URI` uses the `NEXT_PUBLIC` prefix so the variable is accessible in edge functions and middleware configurations. This is useful for configuring operations like Vercel preview deployments.
+  The `NEXT_PUBLIC_WORKOS_REDIRECT_URI` uses the `NEXT_PUBLIC` prefix so the variable is accessible in edge functions and proxy configurations. This is useful for configuring operations like Vercel preview deployments.
 
 - $ frontend="remix"
 
@@ -181,7 +199,7 @@ You can configure the initiate login URL from the _Redirects_ section of the Wor
 
 ## (2) Add AuthKit to your app
 
-Let’s integrate the hosted authentication flow into your app.
+Let's integrate the hosted authentication flow into your app.
 
 - $ frontend="client-only"
 
@@ -219,45 +237,39 @@ Let’s integrate the hosted authentication flow into your app.
 
   <CodeBlock file="authkit-nextjs-provider" title="/app/layout.tsx" />
 
-  ### Middleware
+  ### Proxy
 
-  [Next.js middleware](https://nextjs.org/docs/app/building-your-application/routing/middleware) is required to determine which routes require authentication.
+  [Next.js proxy](https://nextjs.org/docs/app/api-reference/file-conventions/proxy) is required to determine which routes require authentication.
 
-  #### Implementing the middleware
+  #### Implementing the proxy
 
-  When implementing, you can opt to use either the complete `authkitMiddleware` solution or the composable `authkit` method. You'd use the former in cases where your middleware is only used for authentication. The latter is used for more complex apps where you want to have your middleware perform tasks in addition to auth.
+  When implementing the proxy, which [was called middleware before Next 16](https://nextjs.org/docs/messages/middleware-to-proxy), you can opt to use either the complete `authkitMiddleware` solution or the composable `authkit` method. You'd use the former in cases where your proxy is only used for authentication. The latter is used for more complex apps where you want to have your proxy perform tasks in addition to auth.
 
   - | Complete
 
-    The middleware can be implemented in the `middleware.ts` file. This is a full middleware solution that handles all the auth logic including session management and redirects for you.
+    The proxy can be implemented in the `proxy.ts` file. This is a full proxy solution that handles all the auth logic including session management and redirects for you.
 
-    With the complete middleware solution, you can choose between page based auth and middleware auth.
+    With the complete proxy solution, you can choose between page based auth and middleware auth.
 
     #### Page based auth
 
     Protected routes are determined via the use of the `withAuth` method, specifically whether the `ensureSignedIn` option is used. Usage of `withAuth` is covered further down in the _Access authentication data_ section.
 
-    <CodeBlock file="authkit-nextjs-middleware" title="middleware.ts" />
+    <CodeBlock file="authkit-nextjs-proxy" title="proxy.ts" />
 
     #### Middleware auth
 
-    In this mode the middleware is used to protect all routes by default, redirecting users to AuthKit if no session is available. Exceptions can be configured via an allow list.
+    In this mode the proxy is used to protect all routes by default, redirecting users to AuthKit if no session is available. Exceptions can be configured via an allow list.
 
-    <CodeBlock
-      file="authkit-nextjs-middleware-auth-mode"
-      title="middleware.ts"
-    />
+    <CodeBlock file="authkit-nextjs-middleware-auth-mode" title="proxy.ts" />
 
     In the above example, the home page `/` can be viewed by unauthenticated users. The `/account` page and its children can only be viewed by authenticated users.
 
   - | Composable
 
-    The middleware can be implemented in the `middleware.ts` file. This is a composable middleware solution that handles the session management part for you but leaves the redirect and route protection logic to you.
+    The proxy can be implemented in the `proxy.ts` file. This is a composable proxy solution that handles the session management part for you but leaves the redirect and route protection logic to you.
 
-    <CodeBlock
-      file="authkit-nextjs-middleware-composable"
-      title="middleware.ts"
-    />
+    <CodeBlock file="authkit-nextjs-proxy-composable" title="proxy.ts" />
 
   ### Callback route
 
@@ -265,14 +277,11 @@ Let’s integrate the hosted authentication flow into your app.
 
   <CodeBlock file="callback-endpoint-nextjs" title="/app/callback/route.ts" />
 
-  ### Initiate login route
+  ### Sign-in endpoint
 
-  We'll need an initiate login endpoint to direct users to sign in using AuthKit before redirecting them back to your application. We'll do this by generating an AuthKit authorization URL server side and redirecting the user to it.
+  We'll need a sign-in endpoint to direct users to sign in using AuthKit before redirecting them back to your application. We'll do this by generating an AuthKit authorization URL server side and redirecting the user to it.
 
-  <CodeBlock
-    file="initiate-login-endpoint-nextjs"
-    title="/app/login/route.ts"
-  />
+  <CodeBlock file="login-endpoint-nextjs" title="/app/login/route.ts" />
 
   ### Access authentication data
 
@@ -316,7 +325,7 @@ Let’s integrate the hosted authentication flow into your app.
 
   ### Ending the session
 
-  Finally, ensure the user can end their session by redirecting them to the logout URL. After successfully signing out, the user will be redirected to your app's [Logout redirect](/user-management/sessions/configuring-sessions/logout-redirect) location, which is configured in the WorkOS dashboard.
+  Finally, ensure the user can end their session by redirecting them to the logout URL. After successfully signing out, the user will be redirected to your app's [Sign-out redirect](/authkit/sessions/configuring-sessions/sign-out-redirect) location, which is configured in the WorkOS dashboard.
 
   <CodeBlock
     file="get-authkit-url-nextjs-logout"
@@ -331,11 +340,11 @@ Let’s integrate the hosted authentication flow into your app.
 
   <CodeBlock file="callback-endpoint-remix" title="/routes/callback.ts" />
 
-  ### Initiate login route
+  ### Sign-in endpoint
 
-  We'll need an initiate login endpoint to direct users to sign in using AuthKit before redirecting them back to your application. We'll do this by generating an AuthKit authorization URL server side and redirecting the user to it.
+  We'll need a sign-in endpoint to direct users to sign in using AuthKit before redirecting them back to your application. We'll do this by generating an AuthKit authorization URL server side and redirecting the user to it.
 
-  <CodeBlock file="initiate-login-endpoint-remix" title="/routes/login.ts" />
+  <CodeBlock file="login-endpoint-remix" title="/routes/login.ts" />
 
   ### Access authentication data in your Remix application
 
@@ -356,36 +365,28 @@ Let’s integrate the hosted authentication flow into your app.
 
   ### Ending the session
 
-  Finally, ensure the user can end their session by redirecting them to the logout URL. After successfully signing out, the user will be redirected to your app's [Logout redirect](/user-management/sessions/configuring-sessions/logout-redirect) location, which is configured in the WorkOS dashboard.
+  Finally, ensure the user can end their session by redirecting them to the logout URL. After successfully signing out, the user will be redirected to your app's [Sign-out redirect](/authkit/sessions/configuring-sessions/sign-out-redirect) location, which is configured in the WorkOS dashboard.
 
   <CodeBlock
     file="authkit-remix-example-logout"
     title="/app/routes/_index.jsx"
   />
 
-- $ frontend="vanilla, react"
+- $ backend="nodejs, ruby, python"
 
   ### Set up the frontend
 
   To demonstrate AuthKit, we only need a simple page with links to logging in and out.
 
-- $ frontend="vanilla"
-
   <CodeBlock file="frontend-vanilla" title="index.html" />
 
-- $ frontend="react"
-
-  <CodeBlock file="frontend-react" title="App.js" />
-
-- $ frontend="vanilla, react"
-
   Clicking the "Sign in" and "Sign out" links should invoke actions on our server, which we'll set up next.
 
 - $ backend="nodejs, ruby, php, go, python, java"
 
-  ### Add an initiate login endpoint
+  ### Add a sign-in endpoint
 
-  We'll need an initiate login endpoint to direct users to sign in (or sign up) using AuthKit before redirecting them back to your application. This endpoint should generate an AuthKit authorization URL server side and redirect the user to it.
+  We'll need a sign-in endpoint to direct users to sign in (or sign up) using AuthKit before redirecting them back to your application. This endpoint should generate an AuthKit authorization URL server side and redirect the user to it.
 
   You can use the optional state parameter to encode arbitrary information to help restore application `state` between redirects.
 
@@ -413,7 +414,7 @@ Let’s integrate the hosted authentication flow into your app.
 
   ### Add a callback endpoint
 
-  Next, let’s add the callback endpoint (referenced in [Configure a redirect URI](/user-management/1-configure-your-project/configure-a-redirect-uri)) which will exchange the authorization code (valid for 10 minutes) for an authenticated User object.
+  Next, let's add the callback endpoint (referenced in [Configure a redirect URI](/authkit/1-configure-your-project/configure-a-redirect-uri)) which will exchange the authorization code (valid for 10 minutes) for an authenticated User object.
 
 - $ backend="nodejs"
 
@@ -460,6 +461,14 @@ Let’s integrate the hosted authentication flow into your app.
 
   <CodeBlock file="encrypt-session-express" title="server.js" />
 
+  We should also present some of the user information on our frontend. Let's update the default route to read the session cookie and display user information:
+
+  <CodeBlock file="auth-info-session-express" title="server.js" />
+
+  And, we should make sure to update the index page to present this info.
+
+  <CodeBlock file="frontend-vanilla-auth-info" title="index.html" />
+
   ### Protected routes
 
   Then, use middleware to specify which routes should be protected. If the session has expired, use the SDK to attempt to generate a new one.
@@ -472,14 +481,32 @@ Let’s integrate the hosted authentication flow into your app.
 
   ### Ending the session
 
-  Finally, ensure the user can end their session by redirecting them to the logout URL. After successfully signing out, the user will be redirected to your app's [Logout redirect](/user-management/sessions/configuring-sessions/logout-redirect) location, which is configured in the WorkOS dashboard.
+  Finally, ensure the user can end their session by redirecting them to the logout URL. After successfully signing out, the user will be redirected to your app's [Sign-out redirect](/authkit/sessions/configuring-sessions/sign-out-redirect) location, which is configured in the WorkOS dashboard.
 
   <CodeBlock file="log-out-express" title="server.js" />
 
+- $ backend="nodejs"
+
+  <Callout type="warning">
+    <strong>CSRF Protection:</strong> The logout endpoint uses POST to prevent
+    unintended logouts from browser prefetching. CSRF protection with{' '}
+    <code>csrf-csrf</code> prevents cross-site request forgery attacks. The
+    frontend fetches a CSRF token from <code>/csrf-token</code> and includes it
+    in the logout form submission.
+  </Callout>
+
 - $ backend="ruby"
 
   <CodeBlock file="encrypt-session-sinatra" title="server.rb" />
 
+  We should also present some of the user information on our frontend. Let's update the default route to read the session cookie and display user information:
+
+  <CodeBlock file="auth-info-session-sinatra" title="server.rb" />
+
+  And, we should make sure to update the index page to present this info.
+
+  <CodeBlock file="frontend-vanilla-auth-info" title="index.html" />
+
   ### Protected routes
 
   Then, use a helper method to specify which routes should be protected. If the session has expired, use the SDK to attempt to generate a new one.
@@ -492,14 +519,30 @@ Let’s integrate the hosted authentication flow into your app.
 
   ### Ending the session
 
-  Finally, ensure the user can end their session by redirecting them to the logout URL. After successfully signing out, the user will be redirected to your app's [Logout redirect](/user-management/sessions/configuring-sessions/logout-redirect) location, which is configured in the WorkOS dashboard.
+  Finally, ensure the user can end their session by redirecting them to the logout URL. After successfully signing out, the user will be redirected to your app's [Sign-out redirect](/authkit/sessions/configuring-sessions/sign-out-redirect) location, which is configured in the WorkOS dashboard.
 
   <CodeBlock file="log-out-sinatra" title="server.rb" />
 
+  <Callout type="warning">
+    <strong>CSRF Protection:</strong> The logout endpoint uses POST to prevent
+    unintended logouts from browser prefetching. CSRF protection with{' '}
+    <code>Rack::Csrf</code> prevents cross-site request forgery attacks. The{' '}
+    <code>csrf_tag</code> helper method generates a hidden form field with the
+    CSRF token.
+  </Callout>
+
 - $ backend="python"
 
   <CodeBlock file="encrypt-session-flask" title="server.py" />
 
+  We should also present some of the user information on our frontend. Let's update the default route to read the session cookie and display user information:
+
+  <CodeBlock file="auth-info-session-flask.trunk-ignore" title="server.py" />
+
+  And, we should make sure to update the index page to present this info.
+
+  <CodeBlock file="frontend-vanilla-auth-info" title="index.html" />
+
   ### Protected routes
 
   Then, use a decorator to specify which routes should be protected. If the session has expired, use the SDK to attempt to generate a new one.
@@ -512,14 +555,38 @@ Let’s integrate the hosted authentication flow into your app.
 
   ### Ending the session
 
-  Finally, ensure the user can end their session by redirecting them to the logout URL. After successfully signing out, the user will be redirected to your app's Logout redirect location, which is configured in the WorkOS dashboard.
+  Finally, ensure the user can end their session by redirecting them to the logout URL. After successfully signing out, the user will be redirected to your app's Sign-out redirect location, which is configured in the WorkOS dashboard.
 
   <CodeBlock file="log-out-flask.trunk-ignore" title="server.py" />
 
-> If you haven't configured a [Logout redirect](/user-management/sessions/configuring-sessions/logout-redirect) in the WorkOS dashboard, users will see an error when logging out.
+  <Callout type="warning">
+    <strong>CSRF Protection:</strong> The logout endpoint uses POST to prevent
+    unintended logouts from browser prefetching. CSRF protection with{' '}
+    <code>Flask-WTF</code> prevents cross-site request forgery attacks.
+    Flask-WTF automatically validates CSRF tokens on POST requests when
+    configured with <code>CSRFProtect</code>.
+  </Callout>
+
+> If you haven't configured a [Sign-out redirect](/authkit/sessions/configuring-sessions/sign-out-redirect) in the WorkOS dashboard, users will see an error when logging out.
+
+## Validate the authentication flow
+
+- $ frontend="nextjs, remix"
+
+  To test all of this out, call `npm run dev`, navigate to `localhost:3000`, and sign up for an account.
+
+- $ backend="nodejs"
+
+  To test all of this out, start your server with `node server.js`, navigate to `localhost:3000`, and sign up for an account.
+
+- $ backend="ruby"
+
+  To test all of this out, start your server with `ruby server.rb`, navigate to `localhost:3000`, and sign up for an account.
+
+- $ backend="python"
 
-### Validate the authentication flow
+  To test all of this out, start your server with `python server.py`, navigate to `localhost:3000`, and sign up for an account.
 
-Navigate to the authentication endpoint we created and sign up for an account. You can then sign in with the newly created credentials and see the user listed in the _Users_ section of the [WorkOS Dashboard](https://dashboard.workos.com).
+You can then sign in with the newly created credentials and see the user listed in the **Users** section of the [WorkOS Dashboard](https://dashboard.workos.com).
 
 ![Dashboard showing newly created user](https://images.workoscdn.com/images/54fa6e6c-4c6f-4959-9301-344aeb4eeac8.png?auto=format&fit=clip&q=80)

package/.docs/organized/docs/{user-management → authkit}/invitations.mdx

@@ -2,7 +2,7 @@
 title: Invitations
 description: Easily add users to your application or as members of an organization.
 showNextPage: true
-originalPath: .tmp-workos-clone/packages/docs/content/user-management/invitations.mdx
+originalPath: .tmp-workos-clone/packages/docs/content/authkit/invitations.mdx
 ---
 
 ## Introduction
@@ -26,7 +26,7 @@ As part of signing up, they automatically join the organization. If a user is in
 
 ### Inviting existing users to an organization
 
-If an invitation is for an existing user, clicking the link in the email and signing in adds the user as a member to the organization. If the user is already signed in, you can use the invitation code to validate that the signed-in user is eligible to use the invitation, by querying the [Invitation API](/reference/user-management/invitation).
+If an invitation is for an existing user, clicking the link in the email and signing in adds the user as a member to the organization. If the user is already signed in, you can use the invitation code to validate that the signed-in user is eligible to use the invitation, by querying the [Invitation API](/reference/authkit/invitation).
 
 This offers choice for the end-user so that they aren’t automatically added to organizations that may be attempting phishing attacks.
 
@@ -34,11 +34,11 @@ This offers choice for the end-user so that they aren’t automatically added to
 
 Invitations do not have to be specific to an organization. An invitation sent without specifying an organization is an invitation to join the application. This enables your existing users to help grow your application by inviting peers organically.
 
-When signup is disabled, users cannot register for a new account through [AuthKit](/user-management) or the [API](/reference/user-management/invitation). When a valid invitation code is present in the sign-in flow, registration is opened up both in AuthKit and the API so that a new user may sign up. This lets you model your application as a closed-registration invitation-only system.
+When signup is disabled, users cannot register for a new account through [AuthKit](/authkit) or the [API](/reference/authkit/invitation). When a valid invitation code is present in the sign-in flow, registration is opened up both in AuthKit and the API so that a new user may sign up. This lets you model your application as a closed-registration invitation-only system.
 
 ## Sending invitations
 
-Invitations can be sent programmatically by your application with the [Invitation API](/reference/user-management/invitation), or viewed and manually created in the [WorkOS Dashboard](https://dashboard.workos.com/). By default, WorkOS sends these emails, but you can also [send the emails yourself](/user-management/custom-emails).
+Invitations can be sent programmatically by your application with the [Invitation API](/reference/authkit/invitation), or viewed and manually created in the [WorkOS Dashboard](https://dashboard.workos.com/). By default, WorkOS sends these emails, but you can also [send the emails yourself](/authkit/custom-emails).
 
 ![Dashboard displaying a list of user invitations](https://images.workoscdn.com/images/18299a05-f824-410e-a17b-828fbe5826f1.png?auto=format&fit=clip&q=80)
 

package/.docs/organized/docs/{user-management → authkit}/invite-only-signup.mdx

@@ -2,7 +2,7 @@
 title: Invite-only signup
 description: Modeling an invite-only application without a public signup page.
 showNextPage: false
-originalPath: .tmp-workos-clone/packages/docs/content/user-management/invite-only-signup.mdx
+originalPath: .tmp-workos-clone/packages/docs/content/authkit/invite-only-signup.mdx
 ---
 
 ## Introduction
@@ -11,7 +11,7 @@ In this scenario, we outline the considerations, concepts, and best practices fo
 
 ## Goals & requirements
 
-Imagine a company that wishes to model an invite only application that requries an exclusive invite to access. The product is yet to launch, and as the initial release approaches they plan to seed memberships from a small subset of organizations and later allow existing users to invite new members from a quota.
+Imagine a company that wishes to model an invite only application that requires an exclusive invite to access. The product is yet to launch, and as the initial release approaches they plan to seed memberships from a small subset of organizations and later allow existing users to invite new members from a quota.
 
 The requirements are as follows:
 
@@ -63,7 +63,7 @@ Typically, an application will implement a "seed" script which will be run once
 
 Custom invitation controls can be implemented within the application to allow members to invite other members. This generally requires adding a form to the UI to collect the email address of the user to invite alongside a button to trigger the API call. Additionally, a count of the number of invites a user has made might be stored and checked against a quota to ensure they don't exceed the number of invites they are allowed to send.
 
-A call can then be made to [the WorkOS API](/reference/user-management/invitation/send) by supplying the target users email address as well as the ID of the originating organization. The invited user can then accept this invite via email and move through the steps to gain access to the application.
+A call can then be made to [the WorkOS API](/reference/authkit/invitation/send) by supplying the target users email address as well as the ID of the originating organization. The invited user can then accept this invite via email and move through the steps to gain access to the application.
 
 ## Summary
 

package/.docs/organized/docs/authkit/jit-provisioning.mdx

@@ -0,0 +1,42 @@
+---
+title: Just-in-time Provisioning
+description: Automatically provision users and memberships with JIT provisioning.
+showNextPage: true
+originalPath: .tmp-workos-clone/packages/docs/content/authkit/jit-provisioning.mdx
+---
+
+## Introduction
+
+JIT provisioning automatically creates users and organization memberships when a user signs in. This feature allows users to access an organization’s resources without requiring manual invitations from the IT admin.
+
+## Automatically add users with verified domains as members
+
+Users with [verified email domains](/authkit/domain-verification) can be automatically added as members to an organization through the organization's [domain policy](/authkit/organization-policies/domain-policy). This feature is useful when an application or organization wants to automatically group individuals into the same workspace based on their email domain.
+
+![Configuring a domain policy in the dashboard](https://images.workoscdn.com/images/b98493d9-f9fe-475d-a448-f9099558cd19.png?auto=format&fit=clip&q=50)
+
+## SSO JIT provisioning
+
+When a user signs in, WorkOS detects when their email domain matches a verified domain of an organization and prompts the user to sign in through the organization's IdP. If the user existed in WorkOS previously, that existing user is automatically added to the organization. Otherwise, a new user is created and added to the organization.
+
+![Configuring just-in-time provisioning for SSO users in the dashboard](https://images.workoscdn.com/images/90a85516-ed7a-4bd4-88a5-384b2f818436.png?auto=format&fit=clip&q=50)
+
+### Custom attributes
+
+When JIT provisioning creates a membership via SSO, [custom attributes](/sso/attributes) from the SSO Profile are made available on the organization membership's `custom_attributes` field. This allows you to access IdP-sourced attributes in your application via the [organization membership API](/reference/authkit/organization-membership) or [JWT templates](/authkit/jwt-templates).
+
+> If a directory is linked to the membership, the directory user's custom attributes will always take precedence over the SSO profile's attributes.
+
+### Guest provisioning
+
+SSO JIT provisioning is not fully supported for guests whose email domain has not been [verified](/authkit/domain-verification) by the organization.
+
+For example, an IT admin may want to gate all contractor access through their IdP (to enable access revocation across applications) but the contractor prefers to use their own email address.
+
+Instead, guest users must be [invited](/authkit/invitations) to join the organization before they are able to sign in with the organization's IdP.
+
+## Disabling JIT provisioning
+
+Both automatic membership by email domain and SSO JIT provisioning are enabled by default but can be disabled in the [WorkOS Dashboard](https://dashboard.workos.com).
+
+Disabling these features may be useful if the IT admin prefers to manually control membership through [invitations](/authkit/invitations).

package/.docs/organized/docs/{user-management → authkit}/jwt-templates.mdx

@@ -2,12 +2,12 @@
 title: JWT Templates
 description: Customize the claims in your application's access tokens.
 showNextPage: true
-originalPath: .tmp-workos-clone/packages/docs/content/user-management/jwt-templates.mdx
+originalPath: .tmp-workos-clone/packages/docs/content/authkit/jwt-templates.mdx
 ---
 
 ## Introduction
 
-JWT templates allow you to customize the claims in your application's access tokens issued by WorkOS. You can leverage core attributes of users and organizations, in addition to [custom metadata](/user-management/metadata) you set on these objects.
+JWT templates allow you to customize the claims in your application's access tokens issued by WorkOS. You can leverage core attributes of users and organizations, in addition to [custom metadata](/authkit/metadata) you set on these objects.
 
 ---
 
@@ -39,6 +39,40 @@ JWT templates are comprised of a template string which is rendered with the user
   />
 </CodeBlock>
 
+---
+
+## Custom attributes
+
+You can include IdP-sourced attributes in your JWT claims using the `organization_membership.custom_attributes` context. These attributes are available from the linked [Directory User](/reference/directory-sync/directory-user) or [SSO Profile](/reference/sso/profile).
+
+To configure custom attributes, see the [Profile Attributes](/sso/attributes) guide for SSO or the [User Attributes](/directory-sync/attributes) guide for Directory Sync.
+
+### Example
+
+<CodeBlock>
+  <CodeBlockTab
+    language="js"
+    file="jwt-template-custom-attributes.trunk-ignore"
+    title="Template"
+  />
+  <CodeBlockTab
+    language="js"
+    file="jwt-template-custom-attributes-context.trunk-ignore"
+    title="Context"
+  />
+  <CodeBlockTab
+    language="js"
+    file="jwt-template-custom-attributes-output.trunk-ignore"
+    title="Output"
+  />
+</CodeBlock>
+
+### Priority rules
+
+When a membership is linked to both a Directory User and an SSO Profile, the Directory User's `custom_attributes` take precedence. This ensures consistent data when both IdP sources are configured.
+
+---
+
 ## Syntax
 
 ### 1. **Basic Variable Interpolation**
@@ -172,7 +206,7 @@ The rendering engine trims whitespace from the beginning and end of string value
 
 If the template contains invalid syntax, an error will be thrown:
 
-- **Template must render to an object:** If the template does not evaluate to a valid JSON object (e.g., an array or primitive value). Example:
+- **Template must render to an object with at least one explicitly defined top-level key:** If the template does not evaluate to a valid JSON object (e.g., an array or primitive value). Example:
   ```js
   [ {{ user.email }} ]
   ```

package/.docs/organized/docs/authkit/landing.mdx

@@ -0,0 +1,22 @@
+---
+title: Get started with AuthKit
+description: >-
+  Set up AuthKit in your app using either the WorkOS CLI or a manual
+  framework-specific guide.
+hideCopyButton: true
+originalPath: .tmp-workos-clone/packages/docs/content/authkit/landing.mdx
+---
+
+## Install using the WorkOS CLI
+
+Automatically integrate WorkOS into your app with this command. Learn more on [GitHub](https://github.com/workos/workos-cli).
+
+```bash title="WorkOS CLI"
+npx workos@latest
+```
+
+## Or install using your preferred stack
+
+Follow a framework-specific guide to integrate AuthKit manually.
+
+<AuthKitStackGrid />