@workos/mcp-docs-server 0.1.0

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

@@ -0,0 +1,122 @@
+---
+title: SAML Security Considerations
+description: Learn about additional SAML features that WorkOS supports.
+originalPath: .tmp-workos-clone/packages/docs/content/sso/saml-security.mdx
+---
+
+SAML requests and responses each have their own unique confidentiality and integrity features.
+To use [SAML](/glossary/saml) with WorkOS, the only requirement is that the Identity Provider ([IdP](/glossary/idp)) signs the assertions within the SAML authentication response.
+
+However, you may have customers that have stricter configuration requirements or you may simply want to raise the security bar by following recommendations.
+This document details what security features are available, how they can benefit you, your customer and their identity provider.
+
+The parties involved in a SAML authentication request and response flow are:
+
+- Identity Provider
+- Service Provider ([SP](/glossary/sp))
+- User Agent, i.e. a browser
+
+---
+
+## SAML Binding Methods
+
+WorkOS uses the HTTP Redirect binding to transmit SAML authentication requests from the SP to the IdP, and the HTTP POST binding to receive SAML responses from the IdP back to the SP:
+
+- Redirect binding sends the request via HTTP GET, with the SAML message included in the URL.
+- POST binding delivers the response via HTTP POST, with the SAML message in the form body.
+
+---
+
+## SP to IdP security features
+
+The SAML authentication request is a way for the SP to request confirmation that the user they're presented with is who they're claiming to be.
+It is relayed to the IdP via the user agent.
+
+![SAML authentication request options](https://images.workoscdn.com/images/dc5df10c-50dc-4bb0-bede-26d16b197f20.png?auto=format&fit=clip&q=80)
+
+### SAML request signing
+
+To address the opportunity to spoof or tamper with a SAML request to the IdP, the IdP may require that all SP's sign the request.
+To accommodate this there needs to be a pre-existing relationship between the SP and IdP where a key-pair is shared.
+The IdP holds the public key (for verifying the request) and the SP holds the private key (for signing the request).
+
+WorkOS recommends SAML request signing, this is especially important in cases where HTTPS is terminated or interrupted prior to reaching the IdP.
+
+All of our requests embed the `<IssueInstant>` timestamp to allow the IdP to reject stale requests, however to mitigate tamper of this value request signing must be used.\
+(See [SAML 2.0 Security Considerations](https://docs.oasis-open.org/security/saml/v2.0/saml-sec-consider-2.0-os.pdf) sections 5.2.1.2, 6.5.1 for more detail).
+
+| Supported by WorkOS | Enabled by default | Usage recommendation              |
+| ------------------- | ------------------ | --------------------------------- |
+| Yes                 | No                 | Use with any IdP that supports it |
+
+WorkOS supports SAML request signing for all compatible connection types. Please [contact WorkOS support](mailto:support@workos.com) to enable it.
+
+---
+
+## IdP to SP security features
+
+The SAML response is an XML document provided by an IdP containing details about a user so that an SP can authenticate them.
+It is relayed to the SP via the user agent.
+
+![SAML authentication response options](https://images.workoscdn.com/images/f888365e-fa7d-4c1e-a76d-a19777e6cbb2.png?auto=format&fit=clip&q=80)
+
+For reference in understanding the following features, below is a simplified hierarchy of the XML elements in a SAML Response:
+
+```xml title="SAML response"
+<Response>
+  <Assertion>
+    <AttributeStatement>
+      <Attribute>
+        <AttributeValue>...</AttributeValue>
+      </Attribute>
+    </AttributeStatement>
+  </Assertion>
+</Response>
+```
+
+### Signed response assertions
+
+This is **required** by WorkOS for all SAML connections. It is a core requirement for SAML IdPs to implement as of SAML 2.0 (see [SAML 2.0 Profiles](https://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf) section 4.1.3.5).
+
+| Supported by WorkOS | Enabled by default | Usage recommendation                    |
+| ------------------- | ------------------ | --------------------------------------- |
+| Yes                 | Yes                | All WorkOS SAML connections must use it |
+
+Signed response assertions are enabled in the setup steps when you [create a SAML connection](/integrations/saml).
+
+### Signed response message envelope
+
+This is the complete signature over the SAML response payload.
+In combination with an assertion signature it will provide additional integrity protection and is recommended by WorkOS (For details on threats addressed see [SAML Security Considerations](https://docs.oasis-open.org/security/saml/v2.0/saml-sec-consider-2.0-os.pdf) sections 7.1.1.6, 7.1.1.7).
+
+| Supported by WorkOS | Enabled by default | Usage recommendation              |
+| ------------------- | ------------------ | --------------------------------- |
+| Yes                 | No                 | Use with any IdP that supports it |
+
+Please [contact WorkOS support](mailto:support@workos.com) to enable signed response message envelope.
+
+### Encrypted response assertion
+
+The SAML assertions in the SAML response may contain sensitive data, and therefore there is an option to encrypt them to preserve confidentiality.
+
+This feature is recommended in scenarios where the SAML response travels through HTTPS termination, so that accidental logging of sensitive data can be mitigated.
+
+| Supported by WorkOS | Enabled by default | Usage recommendation              |
+| ------------------- | ------------------ | --------------------------------- |
+| Yes                 | No                 | Use with any IdP that supports it |
+
+Please [contact WorkOS support](mailto:support@workos.com) to enable encrypted response assertion.
+
+### Encrypted response attributes
+
+The attribute statement is a sub-element of the assertion, some or all of the attributes in the statement can be encrypted as part of the SAML authentication protocol.
+
+| Supported by WorkOS | Enabled by default | Usage recommendation                 |
+| ------------------- | ------------------ | ------------------------------------ |
+| No                  | No                 | Use **encrypted assertions** instead |
+
+WorkOS does not currently support encrypted response attributes. It is recommended to use assertion encryption to envelope all the attributes if confidentiality is required.
+
+## 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.

package/.docs/organized/docs/sso/signing-certificates.mdx

@@ -0,0 +1,121 @@
+---
+title: SAML Signing Certificates
+description: Verify the authenticity of SAML responses and requests.
+originalPath: .tmp-workos-clone/packages/docs/content/sso/signing-certificates.mdx
+---
+
+SAML signing certificates are X.509 certificates used in SAML responses to allow the [Service Provider (SP)](/glossary/sp) to verify the authenticity of a SAML response. Some [Identity Providers (IdP’s)](/glossary/idp) may require or provide the option to use a SAML signing certificate for the SAML request as well. In these cases the IdP verifies the authenticity of the SAML request.
+
+![SAML Flow Diagram](https://images.workoscdn.com/images/d9771da5-ee40-4e41-bc96-f393ee0af577.png?auto=format&fit=clip&q=80)[border=false]
+
+SAML response signing certificates are generated by your customer’s IdP and must then be uploaded to WorkOS manually or using a monitored metadata URL. Your customer can either upload the certificate themselves via the Admin Portal, or you can upload it for them via the WorkOS Dashboard if your customer provides it to you.
+
+Unlike SAML response signing, for request signing you will need to provide your customer with a metadata URL called the SP metadata URL. Your customer will then upload the SP metadata URL to their IdP, where it will either be monitored for updates automatically made by WorkOS, or it will be manually updated by your customer in their IdP.
+
+---
+
+## SAML Response Signing Certificate
+
+When the IdP sends a SAML response, the SP must verify the authenticity of the response, and that it has not been tampered with by an unauthorized third party. The SAML response signing certificate allows the SP to perform this verification.
+
+### Sample scenario
+
+Consider the fictional SaaS company _HireOS_, which offers recruiting software to other businesses. _HireOS_ is an online application that allows its customers to track leads, candidates, and interviews. _HireOS_ is referred to as the SP by SAML.
+
+Now let’s consider _HireOS_’ newest enterprise customer: _Enterprise Corp_. _Enterprise Corp_ is a large enterprise company that wants to use _HireOS_ to manage their recruiting. _Enterprise Corp_ IT Admins need recruiters and other employees who will use _HireOS_ to log in using _Enterprise Corp_'s identity provider, Okta. Okta is one of many companies known as an IdP to SAML.
+
+### Verifying the SAML response
+
+After identifying the user—whether from the SAML request or from IdP initiated SSO—Okta SAML will generate the SAML response, which includes SAML assertions, the X.509 certificate, and the signature value. Upon receiving the response from Okta SAML, _HireOS_ will verify that the response came from Okta SAML by decrypting the signature, using the public key on the X.509 certificate, and checking if the hash values match.
+
+![SAML Response Diagram](https://images.workoscdn.com/images/96ec0449-2080-4b84-8574-43d1bc24c24a.png?auto=format&fit=clip&q=80)[border=false]
+
+### Planning considerations
+
+When planning your SAML integration, there are a few things to consider related to SAML response signing certificates.
+
+### Certificate expiration
+
+Your SAML response signing certificate will eventually expire and must be kept up to date in order to maintain service. Your certificate’s expiration time will vary, but typically, response certificates are valid anywhere from 1-5 years. If your certificate is uploaded in the WorkOS Dashboard, you can see when it expires by going to Organizations, selecting the Organization, and then clicking on the Connection containing the response certificate. If your company has a shared Slack channel with WorkOS, we will help ensure that your SAML response signing certificates stay up to date by automatically sending a notification before a certificate expires.
+
+![WorkOS Dashboard UI showing a SAML certificate expiration date](https://images.workoscdn.com/images/eee34072-6363-498e-bb10-cc4f2171c98b.png?auto=format&fit=clip&q=90)
+
+### Monitored metadata versus manual upload
+
+There are two options to upload your response certificate to a Connection, both of which can be done either in the WorkOS Dashboard, or by your customer using the Admin Portal.
+
+### Renewing certificates
+
+To facilitate certificate renewal, WorKOS offers the ability to renew SAML certificates through the Admin Portal. When a certificate is nearing expiration (within 90 days), or has already expired, a notification will appear on the Dashboard Overview page with details about the certificate.
+
+![Notification for expired certificate](https://images.workoscdn.com/images/5eba5473-fa61-4d57-bf60-bb9359d61797.png?auto=format&fit=clip&q=50)
+
+Alternatively, you are also able to filter connections that have either expired or expiring connections directly from the Organization page's filters.
+
+![Organization page expired filter](https://images.workoscdn.com/images/9605a48f-bc2f-42b8-b1f5-eb0e5a014198.png?auto=format&fit=clip&q=50)
+
+From the Connection page you can generate an Admin Portal link that WorkOS can email directly to the IT admin. By entering the IT admins' email address, WorkOS will email them with a certificate
+renewal Admin Portal link, and they will be notified about future
+expiring certificates. Alternatively, you can copy the link and share it with them directly.
+
+![Connection page for an expiring certificate](https://images.workoscdn.com/images/c7896f7f-fcde-4440-9f66-8f3dc8445568.png?auto=format&fit=clip&q=50)
+
+The IT Admin will be guided to a step by step flow to renew their certificate; the exact steps will vary based on the IdP.
+
+![IT Admin flow for Entra ID](https://images.workoscdn.com/images/2c8334f2-3784-4e7d-8ba9-f4896da336cb.png?auto=format&fit=clip&q=50)
+
+### Monitored metadata
+
+To streamline this process, you can instead choose to upload a metadata URL to WorkOS that we will automatically keep updated as metadata changes. If your customer's IdP refreshes a certificate, WorkOS will automatically pull in the updated metadata. Your customer can upload a metadata URL to the Admin Portal during setup. Alternatively, they can provide it to your to manually upload via the Dashboard.
+
+![WorkOS Dashboard UI configuring a connection's metadata URL](https://images.workoscdn.com/images/6407b054-9f84-45cf-81bd-35c25b7af0b5.png?auto=format&fit=clip&q=90)
+
+### Manual upload
+
+SP metadata such as the Entity ID, IdP SSO URL, and SAML response signing certificate can be uploaded manually through the Dashboard or the Admin Portal. This may be done either by uploading an XML metadata file, or by individually inputting metadata values. When metadata becomes out of date, such as an X.509 certificate expiring, new information must manually be uploaded. If you would like to upload the data for your customer, they must first send the relevant metadata to you. You can then upload it via the WorkOS Dashboard by navigating to the Organization and selecting the specific Connection.
+
+![WorkOS Dashboard UI manually configuring a connection's Entity ID, IdP URL, and X509 certificate](https://images.workoscdn.com/images/5002b5ca-d94e-40a9-9dec-71575ba24a91.png?auto=format&fit=clip&q=90)
+
+---
+
+## SAML Request Signing Certificate
+
+When the SP sends a SAML request, the IdP must verify that the request is actually coming from the SP and has not been tampered with by an unauthorized third party. IdP’s choose to handle this verification in different ways, and some use a SAML request signing certificate. Microsoft AD FS SAML uses a relying party trust, which is similar to a SAML request signing certificate, and the concepts covered in this article are applicable. In WorkOS, Connections that take advantage of a request certificate will expose an SP metadata URL that can be sent to the IdP in order to give it access to the signing certificate.
+
+### Sample scenario
+
+Once again, let’s consider the fictional SaaS company _HireOS_, which offers recruiting software to other businesses. _HireOS_ is referred to as the SP by SAML.
+
+_HireOS_’ newest enterprise customer is called _Enterprise Corp_. _Enterprise Corp_ IT Admins need recruiters and other employees who will use _HireOS_ to log in using _Enterprise Corp_'s identity provider, Okta. Okta is one of many companies known as an IdP to SAML.
+
+### Verifying the SAML request
+
+In SP initiated SSO, _HireOS_ will first send a SAML request to Okta SAML. If a request certificate is being used, then the X.509 certificate along with a signing signature will be attached to the request. Upon receiving the request, Okta SAML will verify that the request came from _HireOS_ by decrypting the signature using the public key on the X.509 certificate and confirming the hash values match.
+
+![SAML Request Diagram](https://images.workoscdn.com/images/6f244bd0-3f76-434f-99c3-be8bcf65d3da.png?auto=format&fit=clip&q=80)[border=false]
+
+### Planning considerations
+
+When planning your SAML integration, there are a few things to consider related to SAML request signing certificates.
+
+### Certificate expiration
+
+Your SAML request signing certificate will eventually expire and must be kept up to date in order to maintain service. WorkOS will automatically update the request signing certificate on the SP metadata URL before it expires. It is up to your customer and their IdP to either monitor the SP metadata URL, or manually keep it up to date. If your company has a shared Slack channel with WorkOS, you will automatically be notified when the X.509 certificate on the SP metadata URL is updated, so that you can check with your customer that they have the latest metadata.
+
+### Monitored metadata versus manual upload
+
+There are potentially two options for your customer to upload SP metadata, and will vary based on their IdP. In both cases, you will need to provide your customer with the SP metadata URL, which can be found in the WorkOS Dashboard by going to Organizations, selecting the Organization, and then selecting the Connection.
+
+![WorkOS Dashboard UI with SP metadata URL](https://images.workoscdn.com/images/5bab9063-e0cd-4bca-abe6-68db5162be5e.png?auto=format&fit=clip&q=90)
+
+### Monitored metadata
+
+To streamline this process, your customer instead may choose to monitor our SP metadata URL. Their IdP will regularly check our URL for updates to the metadata. When WorkOS makes an update, such as refreshing an X.509 certificate that is expiring soon, their IdP will automatically make the change.
+
+### Manual upload
+
+Your customer can manually download the SP metadata document from the URL, extract the certificate, and upload it to their IdP. When the certificate is getting ready to expire, they can repeat this process to give their IdP the most up to date certificate.
+
+## 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.

package/.docs/organized/docs/sso/single-logout.mdx

@@ -0,0 +1,45 @@
+---
+title: Single Logout
+description: Learn how to implement Single Logout with WorkOS
+featureFlag: single-logout-docs
+originalPath: .tmp-workos-clone/packages/docs/content/sso/single-logout.mdx
+---
+
+> Currently, Single Logout is only supported for [OpenID Connect connections](/integrations/oidc) and limited scenarios.
+> If you are looking to implement this feature, please reach out to [WorkOS support](mailto:support@workos.com).
+
+## RP-initiated Logout
+
+With an Relying-Party-initiated (RP-initiated) logout, a user is logged out of your application and all other applications they are
+logged into via the identity provider. This is achieved by redirecting the user to the [Logout Redirect](/reference/sso/logout/redirect) endpoint.
+
+Before redirecting the user, you need to generate a logout token by calling the
+[Logout Authorize](/reference/sso/logout/authorize) endpoint with the user’s profile ID which can be obtained
+from the [User Profile](/reference/sso/profile/get-profile-and-token) endpoint.
+
+Next, pass the logout token as a query parameter to the [Logout Redirect](/reference/sso/logout/redirect) endpoint.
+
+![RP-initiated logout](https://images.workoscdn.com/images/63a9710b-ff61-456b-aea7-d572b3621271.png?auto=format&fit=clip&q=50)
+
+By following these steps, the user will be securely logged out of your application and all other associated
+applications through the identity provider.
+
+Note that, this feature is only supported for OpenID Connect providers that brings the
+`revocation_endpoint` and `end_session_endpoint` in the OIDC discovery document.
+
+---
+
+## IdP-initiated Logout
+
+For the Identity-Provider-initiated (IdP-initiated) logout, WorkOS provides the `https://auth.workos.com/sso/oidc/idp-logout/:external_key` endpoint
+which needs to be registered in the customer's Identity Provider as the logout endpoint for your application.
+
+When a user logs out of your application via the IdP, the IdP should call this endpoint which will redirect
+to a logout endpoint in your application. This logout endpoint should clear all the cookies in your application.
+
+You should contact [WorkOS support](mailto:support@workos.com) for both:
+
+- obtaining the `https://auth.workos.com/sso/oidc/idp-logout/:external_key` for registering in your customer's IdP
+- informing the logout endpoint in your application.
+
+![IdP-initiated logout](https://images.workoscdn.com/images/aeda8074-7e61-4a3c-850e-278acd510bd8.png?auto=format&fit=clip&q=50)

package/.docs/organized/docs/sso/test-sso.mdx

@@ -0,0 +1,73 @@
+---
+title: Test SSO
+description: |
+  Learn how to test your Single Sign-On integration end-to-end.
+showNextPage: true
+originalPath: .tmp-workos-clone/packages/docs/content/sso/test-sso.mdx
+---
+
+## Testing with the Test Identity Provider
+
+To confirm your Single Sign-On integration works correctly you can use the Test Identity Provider to simulate login flows end-to-end. Your staging environment includes a default Test Organization and active SSO connection configured with the Test Identity Provider.
+
+![WorkOS Test Identity Provider](https://images.workoscdn.com/images/f3b0d507-2d6f-4ed8-a12f-e026c8a2987c.png?auto=format&fit=clip&q=80)
+
+### Getting started
+
+Log into the [WorkOS Dashboard](https://dashboard.workos.com/) and navigate to the _Test SSO_ page to get started with the Test IdP. This page outlines a number of different SSO scenarios you can follow and provides all the necessary information to complete the tests.
+
+![Test SSO WorkOs Dashboard](https://images.workoscdn.com/images/7b7407d7-dcc7-4fd4-859f-4ee4214d69c2.png?auto=format&fit=clip&q=80)
+
+### Service provider-initiated SSO
+
+This case is likely the first [login flow](/sso/login-flows/sp-initiated-sso) you would test when implementing SSO in your app. The test simulates users initiating authentication from your sign-in page. In this scenario, the user enters their email in your app, gets redirected to the identity provider, and then is redirected back to your application.
+
+### Identity provider-initiated SSO
+
+This test simulates users initiating authentication from their identity provider. It is a common [login flow](/sso/login-flows/idp-initiated-sso) that developers forget to consider. In the scenario, users log in to the identity provider directly, select your application from their list of SSO-enabled apps, and are redirected to your application upon successful authentication.
+
+> Ensure [AuthKit is disabled](https://dashboard.workos.com/authentication) before testing.
+
+### Guest email domain
+
+This test simulates users authenticating with an email domain different from the verified domain of the test organization, `example.com`. A relevant scenario is authenticating freelance users, whose email domain is not owned by the company.
+
+### Error response
+
+This test simulates a generic [error response](/reference/sso/get-authorization-url/error-codes) from the user’s identity provider. In this scenario, SSO authentication has failed for the user. Below is an example of the error-related parameters passed to the [redirect URI](/sso/redirect-uris) in your application.
+
+---
+
+## Testing with other identity providers
+
+Test Identity Provider saves time by providing an out of the box experience compared to the configuration process that someone using a real identity provider would have to go through to enable Single Sign-On for your app.
+
+If your integration works with the Test Identity Provider, you can be sure it will work with other identity providers. However, it may be helpful to also learn about the setup process that your customers will go through on their side, which varies depending on a specific identity provider.
+
+### (1) Create an organization
+
+To get started, you will need to [create an organization](https://dashboard.workos.com/organizations) in the WorkOS Dashboard. Organizations in WorkOS represent your customer, so by creating an organization, you can test your SSO connection the way your customers will experience it.
+
+![Create an organization dialog](https://images.workoscdn.com/images/2ef3565c-526a-42e6-9830-622e83b67ee5.png?auto=format&fit=clip&q=80)
+
+### (2) Create a connection
+
+Go to the organization you created and click _Invite admin_. Select _Single Sign-On_ from the list of features. In the next step, enter an email address to send the setup link to, or click _Copy setup link_.
+
+The setup link goes to Admin Portal, where your customers get the exact instructions for every step they need to take to enable Single Sign-On with your app.
+
+> You can also integrate [Admin Portal](/admin-portal) directly into your app to enable self-serve setup of Single Sign-On and other enterprise features for your users.
+
+![Invite an admin dialog](https://images.workoscdn.com/images/b9ab80fc-606a-417c-bade-3483ef48c2ae.png?auto=format&fit=clip&q=80)
+
+### Follow the Admin Portal instructions
+
+To complete the integration, you’ll have to also create an account with the identity provider you want to test with. After you have signed up with an identity provider of your choice, follow the corresponding Admin Portal instructions from the setup link. Once done, you can start testing your SSO integration with that identity provider.
+
+![Admin Portal setup instructions](https://images.workoscdn.com/images/0ee15c3d-5356-4f41-a26a-440f95355b28.png?auto=format&fit=clip&q=80)
+
+The setup instructions you’ve seen in the Admin Portal are also available directly in the docs if you want to create a connection manually:
+
+<ProviderCards.SsoIntegration />
+
+---

package/.docs/organized/docs/sso/ux/sign-in.mdx

@@ -0,0 +1,44 @@
+---
+title: Sign-In UX
+description: User experience considerations for Single Sign-On.
+originalPath: .tmp-workos-clone/packages/docs/content/sso/ux/sign-in.mdx
+---
+
+## Introduction
+
+Now that we’ve seen how the Single Sign-On (SSO) APIs work, you may want to consider how to best integrate this new flow in the sign-in experience for your users. This guide will walk you through a few different approaches you could take in your application:
+
+- Separate SSO flow
+- Separate email and password fields
+- Auto-hide the password field
+
+Throughout this guide, let’s consider the following scenario:
+
+- You are building an app called _Demo App_
+- An organization named _Foo Corp_ is using Single Sign-On with Okta as the [IdP](/glossary/idp)
+
+### Implementing SSO with WorkOS
+
+This document offers guidance on UX best practices when integrating SSO with the standalone API. You might instead consider [WorkOS User Management](/user-management) with AuthKit, a complete authentication platform which handles all of the UX complexity for you.
+
+## Separate SSO flow
+
+A basic approach would be to create a link or button on your login page with a **Sign in with SSO** or **Use Single Sign-On** option. This method differentiates the flows for the user explicitly.
+
+You may still look up the domain if they try to sign in with their corporate email and redirect them to the appropriate flow too—see the demo below as an example.
+
+<SsoDemoSignInWithSso />
+
+As this adds yet another button, one thing to be mindful with this approach is the [NASCAR problem](https://indieweb.org/NASCAR_problem) where a cluster of 3rd party branded buttons creates both visual noise and confusion. Consider only offering a couple of options that are relevant to your user base.
+
+## Separate email and password fields
+
+Instead of asking users for their email and password in one screen, you could first ask them for their email. This method gives you an opportunity to check if a particular domain is SSO-enabled and redirect the user to the appropriate SSO flow. It is a very popular approach employed by many applications (including WorkOS itself, Apple, and Google).
+
+<SsoDemoSeparateFields />
+
+## Auto-hide the password field
+
+Finally, as an extension to the previous approach, you can automatically hide the password field if the user’s domain is SSO-enabled. This feature is a bit more complicated to implement, but provides a more seamless experience for users.
+
+<SsoDemoDynamicPasswordField />

package/.docs/organized/docs/user-management/_navigation.mdx

@@ -0,0 +1,87 @@
+---
+title: User Management
+links:
+  - title: Getting Started
+    links:
+      - title: Quick Start
+        url: /user-management
+      - title: Example Apps
+        url: /user-management/example-apps
+  - title: Modeling Your App
+    links:
+      - title: Introduction and concepts
+        url: /user-management/modeling-your-app
+      - title: SSO with contractors
+        url: /user-management/sso-with-contractors
+      - title: Invite-only signup
+        url: /user-management/invite-only-signup
+  - title: Integrating
+    links:
+      - title: AuthKit
+        url: /user-management/authkit
+      - title: Branding
+        url: /user-management/branding
+      - title: Migrations
+        url: /user-management/migrations
+      - title: Widgets
+        url: /user-management/widgets
+      - title: Actions
+        url: /user-management/actions
+        featureFlag: actions-docs
+      - title: MCP
+        url: /user-management/mcp
+      - title: On-prem Deployment
+        url: /on-prem-deployment
+  - title: Authentication
+    links:
+      - title: Single Sign-On
+        url: /user-management/sso
+      - title: Email + Password
+        url: /user-management/email-password
+      - title: Passkeys
+        url: /user-management/passkeys
+      - title: Social Login
+        url: /user-management/social-login
+      - title: Multi-Factor Auth
+        url: /user-management/mfa
+      - title: Magic Auth
+        url: /user-management/magic-auth
+  - title: Features
+    links:
+      - title: Users and Organizations
+        url: /user-management/users-organizations
+      - title: Sessions
+        url: /user-management/sessions
+      - title: Radar
+        url: /user-management/radar
+      - title: Invitations
+        url: /user-management/invitations
+      - title: Email Verification
+        url: /user-management/email-verification
+      - title: Domain Verification
+        url: /user-management/domain-verification
+      - title: Identity Linking
+        url: /user-management/identity-linking
+      - title: JIT Provisioning
+        url: /user-management/jit-provisioning
+      - title: Roles and Permissions
+        url: /user-management/roles-and-permissions
+      - title: Directory Provisioning
+        url: /user-management/directory-provisioning
+      - title: Organization Policies
+        url: /user-management/organization-policies
+      - title: Impersonation
+        url: /user-management/impersonation
+      - title: Custom Emails
+        url: /user-management/custom-emails
+      - title: Entitlements
+        url: /user-management/entitlements
+      - title: Metadata and External IDs
+        url: /user-management/metadata
+      - title: JWT Templates
+        url: /user-management/jwt-templates
+      - title: Connect
+        url: /user-management/connect
+originalPath: .tmp-workos-clone/packages/docs/content/user-management/_navigation.mdx
+---
+