@workos/mcp-docs-server 0.1.0 → 0.2.0

package/.docs/organized/docs/reference/workos-connect/token/authorization-code-grant/id-token.mdx

@@ -51,7 +51,7 @@ originalPath: >-
 
 #### ID token
 
-The ID token, when requested with the `openid` scope, contains information about the user’s identity, like name and email address.
+The ID token, when requested with the `openid` scope, contains information about the user's identity, like name and email address.
 
 <CodeBlock
   file="token-authorization-code-id-token"

package/.docs/organized/docs/reference/workos-connect/token/{authorization-code-grant/index.mdx → authorization-code-grant.mdx}

@@ -8,6 +8,23 @@ descriptions:
     redirect_uri: >
       The URL to redirect the user to after they have logged in. This must be
       the same redirect URI used in the initial `/oauth2/authorize` request.
+    code_verifier: >
+      The code verifier used for PKCE (Proof Key for Code Exchange). This is the
+      original random string
+
+      that was used to generate the `code_challenge` in the authorization
+      request. Required when using
+
+      PKCE.
+
+
+      **Note:** PKCE is only supported by applications created through Dynamic
+      Client Registration,
+
+      which is required to use MCP (Model Context Protocol) authorization. For
+      setup instructions,
+
+      see our [MCP guide](/authkit/mcp).
 reference:
   curl:
     - url: /reference/workos-connect/token/authorization-code-grant
@@ -30,7 +47,11 @@ reference:
           description: (workos_connect_token_authorization_code_grant.code)
         - key: redirect_uri
           type: string
-          description: (workos_connect_token_authorization_code_grant.code)
+          description: (workos_connect_token_authorization_code_grant.redirect_uri)
+        - key: code_verifier
+          type: string
+          description: (workos_connect_token_authorization_code_grant.code_verifier)
+          optional: true
       returns:
         - key: anonymous
           type: object
@@ -53,7 +74,7 @@ reference:
               type: '"bearer"'
               description: (workos_connect_token_response.token_type)
 originalPath: >-
-  .tmp-workos-clone/packages/docs/content/reference/workos-connect/token/authorization-code-grant/index.mdx
+  .tmp-workos-clone/packages/docs/content/reference/workos-connect/token/authorization-code-grant.mdx
 ---
 
 ### Authorization code grant

package/.docs/organized/docs/reference/workos-connect/token/client-credentials-grant/access-token.mdx

@@ -13,7 +13,7 @@ reference:
         - key: sub
           type: string
           description: |
-            The WorkOS Connect Application’s client ID.
+            The WorkOS Connect Application's client ID.
         - key: org_id
           type: string
           optional: true

package/.docs/organized/docs/reference/workos-connect/token/{client-credentials-grant/index.mdx → client-credentials-grant.mdx}

@@ -40,12 +40,12 @@ reference:
               type: '"bearer"'
               description: (workos_connect_token_response.token_type)
 originalPath: >-
-  .tmp-workos-clone/packages/docs/content/reference/workos-connect/token/client-credentials-grant/index.mdx
+  .tmp-workos-clone/packages/docs/content/reference/workos-connect/token/client-credentials-grant.mdx
 ---
 
 ### Client credentials grant
 
-Used by WorkOS Connect M2M Applications to exchange the app’s credentials for access tokens.
+Used by WorkOS Connect M2M Applications to exchange the app's credentials for access tokens.
 
 <CodeBlock referenceId="workos_connect_token_client_credentials_grant">
   <CodeBlockTab title="Request" file="token-client-credentials-grant-request" />

package/.docs/organized/docs/reference/workos-connect/token/index.mdx

@@ -24,16 +24,17 @@ originalPath: >-
   .tmp-workos-clone/packages/docs/content/reference/workos-connect/token/index.mdx
 ---
 
-## Token
+# Token
 
 This endpoint is called by WorkOS Connect Applications to get access tokens, ID tokens, and refresh tokens, depending on the `grant_type` provided when requested.
 
-This endpoint is authenticated by provided the WorkOS Application’s client ID and client secret in the body of the request.
+This endpoint is authenticated by providing the WorkOS Application's client ID and client secret in the body of the request.
 
-There are three grant types available:
+There are four grant types available:
 
 - [Authorization code](/reference/workos-connect/token/authorization-code-grant)
 - [Refresh token](/reference/workos-connect/token/refresh-token-grant)
 - [Client credentials](/reference/workos-connect/token/client-credentials-grant)
+- [Device code](/reference/workos-connect/cli-auth/device-code-grant)
 
-Each is describe in greater detail below.
+Each is described in greater detail below.

package/.docs/organized/docs/reference/workos-connect/token/refresh-token-grant.mdx

@@ -61,7 +61,7 @@ originalPath: >-
 
 Used by WorkOS Connect OAuth Applications to exchange a refresh token for new access tokens and/or ID tokens. The refresh token is provided when the initial `oauth2/authorize` request is made with the `offline_access` scope.
 
-The [access token](reference/workos-connect/token/authorization-code-grant/access-token) and [ID tokens](reference/workos-connect/token/authorization-code-grant/id-token) issued here are the same as those issued for the initial `authorization_code` grant.
+The [access token](/reference/workos-connect/token/authorization-code-grant/access-token) and [ID tokens](/reference/workos-connect/token/authorization-code-grant/id-token) issued here are the same as those issued for the initial `authorization_code` grant.
 
 <CodeBlock referenceId="workos_connect_token_refresh_token_grant">
   <CodeBlockTab title="Request" file="token-refresh-token-grant-request" />

package/.docs/organized/docs/reference/workos-connect/userinfo/index.mdx

@@ -34,9 +34,9 @@ originalPath: >-
   .tmp-workos-clone/packages/docs/content/reference/workos-connect/userinfo/index.mdx
 ---
 
-## User information
+# User information
 
-Provides information about the [User](/reference/user-management/user) referenced by the access token’s `sub` claim. Which claims are returned depends on the scopes originally granted when the access token was issued.
+Provides information about the [User](/reference/authkit/user) referenced by the access token’s `sub` claim. Which claims are returned depends on the scopes originally granted when the access token was issued.
 
 This endpoint is authenticated by providing the previously acquired access token in the `Authorization` header.
 

package/.docs/organized/docs/sdks/authkit-js.mdx

@@ -0,0 +1,14 @@
+---
+originalPath: .tmp-workos-clone/packages/docs/content/sdks/authkit-js.mdx
+---
+## Installation
+
+```bash
+npm install @workos-inc/authkit-js
+```
+
+## Usage
+
+The AuthKit JavaScript SDK provides a client-side library for integrating AuthKit authentication into vanilla JavaScript applications.
+
+Refer to the [AuthKit documentation](/authkit) for detailed usage instructions and examples.

package/.docs/organized/docs/sdks/authkit-nextjs.mdx

@@ -0,0 +1,14 @@
+---
+originalPath: .tmp-workos-clone/packages/docs/content/sdks/authkit-nextjs.mdx
+---
+## Installation
+
+```bash
+npm install @workos-inc/authkit-nextjs
+```
+
+## Usage
+
+The AuthKit Next.js SDK provides server-side and client-side utilities for integrating AuthKit authentication into Next.js applications.
+
+Refer to the [AuthKit documentation](/authkit) for detailed usage instructions and examples.

package/.docs/organized/docs/sdks/authkit-react-router.mdx

@@ -0,0 +1,14 @@
+---
+originalPath: .tmp-workos-clone/packages/docs/content/sdks/authkit-react-router.mdx
+---
+## Installation
+
+```bash
+npm install @workos-inc/authkit-react-router
+```
+
+## Usage
+
+The AuthKit React Router SDK provides utilities for integrating AuthKit authentication into React Router 7+ applications.
+
+Refer to the [AuthKit documentation](/authkit) for detailed usage instructions and examples.

package/.docs/organized/docs/sdks/authkit-react.mdx

@@ -0,0 +1,14 @@
+---
+originalPath: .tmp-workos-clone/packages/docs/content/sdks/authkit-react.mdx
+---
+## Installation
+
+```bash
+npm install @workos-inc/authkit-react
+```
+
+## Usage
+
+The AuthKit React SDK provides React hooks and components for integrating AuthKit authentication into React applications.
+
+Refer to the [AuthKit documentation](/authkit) for detailed usage instructions and examples.

package/.docs/organized/docs/sdks/authkit-remix.mdx

@@ -0,0 +1,14 @@
+---
+originalPath: .tmp-workos-clone/packages/docs/content/sdks/authkit-remix.mdx
+---
+## Installation
+
+```bash
+npm install @workos-inc/authkit-remix
+```
+
+## Usage
+
+The AuthKit Remix SDK provides utilities for integrating AuthKit authentication into Remix applications.
+
+Refer to the [AuthKit documentation](/authkit) for detailed usage instructions and examples.

package/.docs/organized/docs/sdks/authkit-tanstack-start.mdx

@@ -0,0 +1,14 @@
+---
+originalPath: .tmp-workos-clone/packages/docs/content/sdks/authkit-tanstack-start.mdx
+---
+## Installation
+
+```bash
+npm install @workos-inc/authkit-tanstack-start
+```
+
+## Usage
+
+The AuthKit TanStack Start SDK provides utilities for integrating AuthKit authentication into TanStack Start applications.
+
+Refer to the [AuthKit documentation](/authkit) for detailed usage instructions and examples.

package/.docs/organized/docs/sso/_navigation.mdx

@@ -13,6 +13,8 @@ links:
     links:
       - title: Sign-In
         url: /sso/ux/sign-in
+      - title: SSO Sessions
+        url: /sso/ux/sessions
   - title: Going Live
     links:
       - title: Login Flows
@@ -31,10 +33,14 @@ links:
         url: /sso/launch-checklist
       - title: FAQ for IT teams
         url: /sso/it-team-faq
-      - title: SAML Security
-        url: /sso/saml-security
       - title: On-prem Deployment
         url: /on-prem-deployment
+  - title: Security
+    links:
+      - title: SAML Security
+        url: /sso/saml-security
+      - title: Sign-in Consent
+        url: /sso/sign-in-consent
   - title: Mapping Roles
     links:
       - title: IdP Role Assignment

package/.docs/organized/docs/sso/attributes.mdx

@@ -34,13 +34,13 @@ Every SSO Profile comes with the following standard attributes. These are the co
 
 ## Custom attributes
 
-For more detailed user information, you can opt-in to additional predefined attributes and define your own custom attributes. These attributes will appear in the `custom_attributes` field on [SSO Profile](/reference/sso/profile) objects and can be configured in the [WorkOS Dashboard](https://dashboard.workos.com/).
+For more detailed user information, you can opt-in to additional predefined attributes and define your own custom attributes. These attributes will appear in the custom attributes field on [SSO Profile](/reference/sso/profile) objects and can be configured in the [WorkOS Dashboard](https://dashboard.workos.com/).
 
-> Custom attributes are currently only supported for SAML SSO connections. If you are interested in custom attributes for OIDC and OAuth connections, please reach out to [support](mailto:support@workos.com).
+> When using AuthKit, SSO Profile custom attributes are also available on the organization membership's `custom_attributes` field. See [JWT Templates](/authkit/jwt-templates) for how to include these in your access tokens.
 
 ### Predefined attributes
 
-When enabled, organization admins will we asked to map these attributes during SSO configuration in [Admin Portal](/admin-portal). These fields are always optional if enabled. These fields are named and schematized by WorkOS – they cannot be renamed.
+When enabled, organization admins will be asked to map these attributes during SSO configuration in [Admin Portal](/admin-portal). These fields are always optional if enabled. These fields are named and schematized by WorkOS – they cannot be renamed.
 
 | Attribute               | Type and description                                                                                                            | Status   |
 | ----------------------- | ------------------------------------------------------------------------------------------------------------------------------- | -------- |
@@ -95,6 +95,18 @@ The environment-level setting is controlled on the Identity Provider Attributes
 
 Organization-level settings are controlled on an individual organization's Attributes tab in the [WorkOS Dashboard](https://dashboard.workos.com/). Organizations mirror the environment-level settings by default.
 
+## Raw attributes [Deprecated]
+
+The `raw_attributes` field on [SSO Profile](/reference/sso/profile) objects is deprecated and will **stop returning data on April 15, 2026**.
+
+[Custom attributes](/sso/attributes/custom-attributes/custom-attributes) are the recommended replacement. Define the attributes you need in the [WorkOS Dashboard](https://dashboard.workos.com/), and your customers' IT admins can map them during SSO connection setup in the [Admin Portal](/admin-portal).
+
+Contact support [via email](mailto:support@workos.com) or Slack if you need help with the migration. We also have tooling to automate the WorkOS-side configuration on your behalf.
+
+For a full migration walkthrough covering Directory Sync, SSO, and AuthKit, see the [migration guide](/deprecations/raw-attributes).
+
+---
+
 ## Frequently asked questions
 
 ### Which identity providers support mapping additional predefined and custom attributes?

package/.docs/organized/docs/sso/domains.mdx

@@ -8,15 +8,17 @@ originalPath: .tmp-workos-clone/packages/docs/content/sso/domains.mdx
 
 When an [Organization](/reference/organization) is created in the WorkOS Dashboard or the [Create Organization API](/reference/organization/create), one or more domains can be associated with the organization.
 
-Domains added to an organization need to be verified. In the API, they can be initially added `'pending'` verification, and later verified using the [Domain Verification API](/domain-verification). Or, if previously verified through other means, can be added as `'verified'`.
+Domains added to an organization need to be verified in order to activate SSO. When creating an organization via the API, domains can be initially added as either `'verified'` if already trusted, or `'pending'` if further verification is required.
 
-> Domains in the WorkOS Dashboard are always considered verified.
+If added as `'pending'`, the domain can later be verified via the WorkOS Dashboard, by an IT admin via the self-serve [Admin Portal](/domain-verification/) flow, or through successful [DNS verification](/domain-verification/api).
+
+> Domains manually added in the WorkOS Dashboard are automatically considered verified.
 
 ## Email validation
 
-During authentication, WorkOS uses these domains to verify the user signing in through the organization's [Connection](/reference/sso/connection) belongs to one of these domains. If the domain of the user's email address does not match one of the organization's domains (or the organization has no verified domains) they will sent to your [Redirect URI](/sso/redirect-uris) with a [`profile_not_allowed_outside_organization`](/reference/sso/get-authorization-url/error-codes) error.
+During authentication, WorkOS uses these domains to verify the user signing in through the organization's [Connection](/reference/sso/connection) belongs to one of these domains. If the domain of the user's email address does not match one of the organization's domains (or the organization has no verified domains) they will be sent to your [Redirect URI](/sso/redirect-uris) with a [`profile_not_allowed_outside_organization`](/reference/sso/get-authorization-url/error-codes) error.
 
-Rejecting users with non-matching email domains prevents the impersonation of users in other organizations. This would otherwise be possible since many Identity Providers allow IT admins to create user accounts with _any_ email address, regardless if the IT admin actually controls the email address or its domain.
+Rejecting users with non-matching email domains prevents the impersonation of users in other organizations. This would otherwise be possible since many Identity Providers allow IT admins to create user accounts with _any_ email address, regardless of whether the IT admin actually controls the email address or its domain.
 
 For example, an IT admin of an organization with the domain `foo.com` can create a user account for `user@bar.com` in their Identity Provider and then sign in as that user. If the application were to receive the profile and naively look up the user record using _only_ the email address, then the IT admin will have gained access to the `user@bar.com` account.
 
@@ -46,7 +48,7 @@ Important data from the SSO profile includes the `id` and the `organization_id`.
   // provisioning to within the organization that matches this ID.
   "organization_id": "org_01EHWNCE74X7JSDV0X3SZ3KJNY",
 
-  // Only match based on email or email domain unless if are
+  // Only match based on email or email domain unless you are
   // filtering potential matches by the organization ID above.
   "email": "todd@example.com"
 
@@ -54,7 +56,7 @@ Important data from the SSO profile includes the `id` and the `organization_id`.
 }
 ```
 
-Here's a updated version of the WorkOS callback endpoint from the [Quick Start guide](/sso/1-add-sso-to-your-app/add-a-callback-endpoint) with examples of these checks added:
+Here's an updated version of the WorkOS callback endpoint from the [Quick Start guide](/sso/1-add-sso-to-your-app/add-a-callback-endpoint) with examples of these checks added:
 
 ```javascript langauge="JavaScript" title="WorkOS callback"
 const { WorkOS } = require('@workos-inc/node');

package/.docs/organized/docs/sso/example-apps.mdx

@@ -1,10 +1,10 @@
 ---
 title: Example Apps
-description: "View sample Single\_Sign-On apps for\_each\_SDK."
+description: View sample Single Sign-On apps for each SDK.
 originalPath: .tmp-workos-clone/packages/docs/content/sso/example-apps.mdx
 ---
 
-You can view minimal example apps that demonstrate how to use the WorkOS SDKs to authenticate users via SSO:
+You can view minimal example apps that demonstrate how to use the WorkOS SDKs to authenticate users via SSO:
 
 <ExampleApps.Root>
   <ExampleApps.Card

package/.docs/organized/docs/sso/identity-provider-role-assignment.mdx

@@ -12,27 +12,7 @@ originalPath: >-
 
 A role represents a logical grouping of permissions, defining access control levels for users within your application. Roles are identified by a unique, immutable slug and are assigned to [SSO user profiles](/reference/sso/profile) through their identity provider group memberships. These group role mappings can be configured on the WorkOS dashboard.
 
-## Configure roles
-
-You can manage roles in the _Roles & Permissions_ section of the [WorkOS Dashboard](https://dashboard.workos.com/).
-
-![Roles section WorkOS Dashboard](https://images.workoscdn.com/images/d96e9c84-651d-4f5d-af3e-98e3d36b7a9f.png?auto=format&fit=clip&q=50)
-
-### Default role
-
-Role configuration occurs at the environment level. Each environment is seeded with a default `member` role, which is automatically assigned to every new profile. The default role cannot be deleted, but any role can be set as the default.
-
-If you need to set default roles or other role configurations at the organization level, refer to the [organization roles](/user-management/roles-and-permissions/organization-roles) documentation.
-
-### Priority order
-
-Role priority order determines which role is assigned when a user sign-ins with multiple groups that contain conflicting role mappings. In that scenario, the role with the highest priority will be assigned. For example, there might be a case where an employee _Jane_ is an _Engineering Manager_ and belongs to an “Engineering”, “Manager”, and “Admin” group. With group-based role assignment, the user will be assigned the role that has the highest priority defined.
-
-### Delete roles
-
-When a role is deleted, all SSO user profiles with that role will be granted the default role.
-
-> To migrate from one default role to another, set the new default role and delete the old one. SSO user profiles will then receive the new default role at the next sign-in.
+To utilize Identity Provider (IdP) role assignment, you must first [configure roles](/rbac/configuration).
 
 ## SSO group role assignment
 
@@ -44,7 +24,7 @@ Based on these settings, SSO user profiles returned from WorkOS will include a r
 
 ![Session page showing user profile with role defined](https://images.workoscdn.com/images/ceea13ba-bf6b-4ea1-a25c-0a08e8833fb0.png?auto=format&fit=clip&q=50)
 
-> Supported in both SAML and OIDC-based connection types, except for Okta OIDC. [Reach out to us](mailto:support@workos.com) if you need this for an Okta OIDC connection.
+> Supported in both SAML and OIDC-based connection types, except for Google OIDC due to [a limitation](https://issuetracker.google.com/issues/133774835?pli=1) with the groups claim.
 
 ### Sample scenario
 
@@ -52,19 +32,19 @@ Consider the fictional SaaS company _HireOS_. _HireOS_ has set up an SSO Connect
 
 1. Create an “Engineering” group using their identity provider.
 2. Configure the `groups` attribute in their SAML app to return the group memberships.
-3. Provide the developer with the IdP ID for the "Engineering" group.
+3. Provide the developer with the IdP Group ID for the "Engineering" group.
 
-In the WorkOS dashboard, the developer can then assign users of that group to the role "Developer".
+In the WorkOS dashboard, the developer can then assign users of that group to the role "Engineer".
 
 1. Navigate to the _Connection_ section of the WorkOS dashboard.
 
 ![SSO group role assignment card](https://images.workoscdn.com/images/28606b9b-fd5b-4219-8b8f-3a640295e784.png?auto=format&fit=clip&q=50)
 
-2. Create an SSO group defining the IdP ID for the "Engineering" group. Then, assign this group to the "Developer" role.
+2. Create an SSO group defining the IdP Group ID for the "Engineering" group. Then, assign this group to the "Engineer" role.
 
 ![Dialog to create connection group with role assignment](https://images.workoscdn.com/images/648410f3-1b82-4ebd-97f3-a8f6edbdd27e.png?auto=format&fit=clip&q=50)
 
-From this point on, whenever a user in the "Engineering" group authenticates via SSO, they will be granted the "Developer” role for that session from the WorkOS API. The role will be returned in the [profile response](/reference/sso/profile).
+From this point on, whenever a user in the "Engineering" group authenticates via SSO, they will be granted the "Engineer" role for that session from the WorkOS API. The role will be returned in the [profile response](/reference/sso/profile).
 
 ```json language="json" title="SSO user profile"
 {
@@ -78,17 +58,37 @@ From this point on, whenever a user in the "Engineering" group authenticates via
   "last_name": "Rundgren",
   "idp_id": "00u1a0ufowBJlzPlk357",
   "role": {
-    "slug": "developer"
+    "slug": "engineer"
   },
-  "raw_attributes": {}
+  "roles": [
+    {
+      "slug": "engineer"
+    }
+  ]
 }
 ```
 
-> When a user is not a member of any groups or their groups do not match any SSO group role assignments, the user will be granted the [default role](/sso/identity-provider-role-assignment/configure-roles/default-role) in the SSO profile.
+> When a user is not a member of any groups or their groups do not match any SSO group role assignments, the user will be granted the [default role](/rbac/configuration/configure-roles/default-role) in the SSO profile.
+
+### Multiple roles
+
+When [multiple roles is enabled](/rbac/configuration/configure-roles/multiple-roles), a user can be assigned multiple roles from their identity provider group memberships. If a user belongs to multiple mapped groups, they will receive all corresponding roles in their SSO profile.
+
+For example, if a user is a member of both "Engineering" and "Design" groups, and both groups are mapped to roles, the user will receive both the "Engineer" and "Designer" roles. If a user is not a member of any groups with explicit mappings, they will receive the [default role](/rbac/configuration).
+
+#### Use cases
+
+By default, multiple roles is disabled and users can only have a single role per entity. It's recommended to start with a single-role setup for simplicity, where it's easier to maintain consistent and correct access patterns.
+
+You might want to enable multiple roles when you need:
+
+- **Cross-department collaboration**: e.g., designers who need some engineering permissions.
+- **Additive, disjoint permissions**: independent permission sets that should stack.
+- **Temporary access**: grant time-bound extra capabilities without creating hybrid roles.
 
 ### Role assignment in Admin Portal
 
-Once [roles](/sso/identity-provider-role-assignment/configure-roles) are configured for your application, enable SSO group role assignment in [Admin Portal](/admin-portal) to allow IT admins to assign roles to groups during SSO connection setup. If enabled, all Admin Portal sessions for SSO connections will have the ability to configure and assign roles to groups.
+Once [roles](/rbac/configuration) are configured for your application, enable SSO group role assignment in [Admin Portal](/admin-portal) to allow IT admins to assign roles to groups during SSO connection setup. If enabled, all Admin Portal sessions for SSO connections will have the ability to configure and assign roles to groups.
 
 ![Enable SSO group role assignment dashboard setting](https://images.workoscdn.com/images/04f86ccc-87a1-4db6-bd54-54a685d409ef.png?auto=format&fit=clip&q=50)
 

package/.docs/organized/docs/sso/index.mdx

@@ -1,6 +1,8 @@
 ---
 title: Single Sign-On
-description: "Facilitate greater security, easier account management, and\_accelerated application onboarding and adoption."
+description: >-
+  Facilitate greater security, easier account management, and accelerated
+  application onboarding and adoption.
 showNextPage: true
 originalPath: .tmp-workos-clone/packages/docs/content/sso/index.mdx
 ---
@@ -13,9 +15,9 @@ There are two ways to integrate Single Sign-On (SSO) with WorkOS:
 
 The standalone API (covered in this document), is a standalone API for integrating into an existing auth stack.
 
-### (B) Using WorkOS User Management
+### (B) Using WorkOS AuthKit
 
-[User Management](/user-management) is a complete authentication platform which includes SSO out of the box.
+[AuthKit](/authkit) is a complete authentication platform which includes SSO out of the box.
 
 ## How Single Sign-On works
 
@@ -271,14 +273,13 @@ Go to the [Redirects](https://dashboard.workos.com/redirects) page in the dashbo
 
 Multi-tenant apps will typically have a single redirect URI specified. You can set multiple redirect URIs for single-tenant apps. You’ll need to be sure to specify which redirect URI to use in the WorkOS client call to fetch the authorization URL.
 
-> WorkOS staging environments allow wildcard characters in redirect URIs. More information about wildcard characters support can be found in the [Redirect URIs](/sso/redirect-uris/wildcard-characters) guide.
-> Query parameters are not allowed in any environment.
+> More information about wildcard characters support can be found in the [Redirect URIs](/sso/redirect-uris/wildcard-characters) guide.
 
 ![Redirects in the Dashboard](https://images.workoscdn.com/images/195dbff3-adbf-4010-b07c-ffc73ceeca68.png?auto=format&fit=clip&q=90)
 
 ### Identity provider-initiated SSO
 
-Normally, the default redirect URI you configure in the WorkOS dashboard is going to be used for all identity provider-initiated SSO sessions. This is because the WorkOS client is not used to initiate the authentication flow.
+Normally, the default redirect URI you configure in the WorkOS dashboard is going to be used for all identity provider-initiated SSO sessions. This is because the WorkOS client is not used to initiate the authentication flow.
 
 However, your customer can specify a separate redirect URI to be used for all their IdP-initiated sessions as a `RelayState` parameter in the SAML settings on their side.
 

package/.docs/organized/docs/sso/it-team-faq.mdx

@@ -6,7 +6,7 @@ originalPath: .tmp-workos-clone/packages/docs/content/sso/it-team-faq.mdx
 
 ## What is WorkOS?
 
-WorkOS is a software company that provides a suite of products to make an app enterprise-ready. These products include Single Sign-On, Directory Sync, and User Management, among others.
+WorkOS is a software company that provides a suite of products to make an app enterprise-ready. These products include Single Sign-On, Directory Sync, and AuthKit (user management), among others.
 
 Developers integrate WorkOS services into their apps in order to provide a secure authentication and user provisioning experience. It’s trusted by companies like Webflow, Plaid, Vercel, and many others.
 

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

@@ -75,8 +75,7 @@ You can use the WorkOS SSO profile `id` attribute as the unique identifier for t
   "idp_id": "00u1a0ufowBJlzPlk357",
   "role": {
     "slug": "admin"
-  },
-  "raw_attributes": {}
+  }
 }
 ```
 
@@ -98,4 +97,4 @@ A linking field (e.g. `email`) should be established to find a current user with
 
 ## Implementing SSO with WorkOS
 
-This document offers guidance to integrate Single Sign-On with our standalone API into your existing auth stack. You might also want to look at [User Management](/user-management), a complete authentication platform that leverages Single Sign-On functionality out of the box, following best practices.
+This document offers guidance to integrate Single Sign-On with our standalone API into your existing auth stack. You might also want to look at [AuthKit](/authkit), a complete authentication platform that leverages Single Sign-On functionality out of the box, following best practices.

package/.docs/organized/docs/sso/launch-checklist.mdx

@@ -11,7 +11,7 @@ originalPath: .tmp-workos-clone/packages/docs/content/sso/launch-checklist.mdx
 
 ### Before you start
 
-This document offers guidance to integrate Single Sign-On with our standalone API into your existing auth stack. You might also want to look at [User Management](/user-management), a complete authentication platform that leverages Single Sign-On functionality out of the box, following best practices.
+This document offers guidance to integrate Single Sign-On with our standalone API into your existing auth stack. You might also want to look at [AuthKit](/authkit), a complete authentication platform that leverages Single Sign-On functionality out of the box, following best practices.
 
 ## Create an IP Allowlist
 
@@ -52,7 +52,7 @@ Yes. For example, let’s say the `http://schemas.xmlsoap.org/ws/2005/05/identit
 
 ### What does the “Allow Profiles Outside Organization” option do?
 
-By default, WorkOS restricts user profiles for SAML Connections to profiles that have email domains that are in the set of [User Email Domains](/reference/organization-domain) on the Organization.
+By default, WorkOS restricts user profiles for SAML Connections to profiles that have email domains that are in the set of [User Email Domains](/reference/domain-verification) on the Organization.
 
 Enabling this option removes this restriction and allows user profiles with any email address to sign in through Connections under this Organization.
 

package/.docs/organized/docs/sso/login-flows.mdx

@@ -1,6 +1,6 @@
 ---
 title: Login Flows
-description: "Learn the differences between SP‑initiated and IdP‑initiated\_SSO."
+description: Learn the differences between SP‑initiated and IdP‑initiated SSO.
 originalPath: .tmp-workos-clone/packages/docs/content/sso/login-flows.mdx
 ---
 
@@ -40,7 +40,7 @@ Your application will also be able to retrieve the [Profile object](/reference/s
   "idp_id": "00u1a0ufowBJlzPlk357",
   "last_name": "Rundgren",
   "object": "profile",
-  "raw_attributes": {}
+  "custom_attributes": {}
 }
 ```
 
@@ -98,4 +98,4 @@ The error callback will include the connection and organization ID’s, which ca
 
 ## Implementing SSO with WorkOS
 
-This document offers guidance to integrate Single Sign-On with our standalone API into your existing auth stack. You might also want to look at [User Management](/user-management), a complete authentication platform that leverages Single Sign-On functionality out of the box, following best practices.
+This document offers guidance to integrate Single Sign-On with our standalone API into your existing auth stack. You might also want to look at [AuthKit](/authkit), a complete authentication platform that leverages Single Sign-On functionality out of the box, following best practices.

package/.docs/organized/docs/sso/redirect-uris.mdx

@@ -18,7 +18,7 @@ In WorkOS Production Environments, the Redirect URI to your application cannot u
 
 There should be at least one redirect URI configured and selected as a default for a WorkOS Environment. This can be done from the [Redirects](https://dashboard.workos.com/redirects) page in the WorkOS dashboard. If you try to route the authorization flow to a Redirect URI that is not yet defined in the Dashboard it will result in an error and users will be unable to sign in, so it’s important to define them in the dashboard first.
 
-![Dashboard UI showing redirects](https://images.workoscdn.com/images/f5d55c0d-0932-41c9-a372-09a9606cc5bb.png?auto=format&fit=clip&q=90)
+![Dashboard Redirect URIs](https://images.workoscdn.com/images/6da31d23-c823-4557-8403-b38b2700e4d2.png?auto=format&fit=clip&q=50)
 
 The Redirect URI can also be included directly in the Get Authorization URL call as a redirect_uri parameter. When the Redirect URI is set in this fashion, it will override the default Redirect URI that is set in the WorkOS Dashboard.
 
@@ -26,19 +26,30 @@ The Redirect URI can also be included directly in the Get Authorization URL call
 
 ## Wildcard characters
 
-WorkOS supports using wildcard characters in Redirect URIs for staging environments.
+WorkOS supports using wildcard characters (`*`) in Redirect URIs to handle dynamic subdomains or variable ports during development.
 
-![WorkOS Dashboard UI editing a wildcard character in a redirect URI](https://images.workoscdn.com/images/951f3dc0-d654-48dd-af00-15f68e2880e5.png?auto=format&fit=clip&q=90)
+![Dashboard updating the redirect URIs to use a wildcard in staging](https://images.workoscdn.com/images/12f99da0-ef62-4b09-acf8-b3d05b48f9e3.png?auto=format&fit=clip&q=50)
 
-The `*` symbol can be used as a wildcard for subdomains; however, it must be used in accordance with the following rules in order to properly function.
+### Subdomains
 
-- The protocol of the URL **must not** be `http:` in Production Environments.
-- The wildcard **must** be located in a subdomain within the hostname component. For example, `http://*.com` will not work.
-- The wildcard **must** be located in the subdomain which is furthest from the root domain. For example, `https://sub.*.example.com` will not work.
-- The URL **must not** contain more than one wildcard. For example, `https://*.*.example.com` will not work.
-- A wildcard character **may** be prefixed and/or suffixed with additional valid hostname characters. For example, `https://prefix-*-suffix.example.com` will work.
-- A URL with a valid wildcard **will not** match a URL more than one subdomain level in place of the wildcard. For example, `https://*.example.com` will not work with `https://sub1.sub2.example.com`.
+The `*` symbol can be used as a wildcard for subdomains; however, it must be used in accordance with the following rules:
+
+- The protocol of the URL **must not** be `http:` in production environments.
+- The wildcard **must** be located in the subdomain furthest from the root domain (e.g., `https://*.sub.example.com` will work, but `https://sub.*.example.com` will not).
+- The URL **must not** contain more than one wildcard.
+- A wildcard character **may** be prefixed and/or suffixed (e.g., `https://prefix-*-suffix.example.com`).
+- A wildcard **will not** match across multiple subdomain levels (e.g., `https://*.example.com` will not match `https://sub1.sub2.example.com`).
+- Wildcards cannot be used with [public suffix domains](https://publicsuffix.org) (e.g., `https://*.ngrok-free.app` will not work).
+- The wildcard will match letters, digits, hyphens, and underscores.
+- A URL with a wildcard cannot be set as the default redirect URI.
+
+### Ports
+
+To support [RFC 8252](https://datatracker.ietf.org/doc/html/rfc8252#section-7.3) ("OAuth 2.0 for Native Apps") and local development, a wildcard may be used in place of the port number.
+
+- This is strictly limited to `localhost` and loopback IP addresses (e.g., `127.0.0.1`).
+- Example: `http://localhost:*/auth/callback` is valid.
 
 ## Implementing SSO with WorkOS
 
-This document offers guidance to integrate Single Sign-On with our standalone API into your existing auth stack. You might also want to look at [User Management](/user-management), a complete authentication platform that leverages Single Sign-On functionality out of the box, following best practices.
+This document offers guidance to integrate Single Sign-On with our standalone API into your existing auth stack. You might also want to look at [AuthKit](/authkit), a complete authentication platform that leverages Single Sign-On functionality out of the box, following best practices.

package/.docs/organized/docs/sso/saml-security.mdx

@@ -119,4 +119,4 @@ WorkOS does not currently support encrypted response attributes. It is recommend
 
 ## Implementing SSO with WorkOS
 
-This document offers guidance to integrate Single Sign-On with our standalone API into your existing auth stack. You might also want to look at [User Management](/user-management), a complete authentication platform that leverages Single Sign-On functionality out of the box, following best practices.
+This document offers guidance to integrate Single Sign-On with our standalone API into your existing auth stack. You might also want to look at [AuthKit](/authkit), a complete authentication platform that leverages Single Sign-On functionality out of the box, following best practices.