@workos/mcp-docs-server 0.1.0 → 0.2.0

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

@@ -2,7 +2,7 @@
 title: Branding
 description: Customize AuthKit to fit natively with your app’s unique design.
 showNextPage: true
-originalPath: .tmp-workos-clone/packages/docs/content/user-management/branding.mdx
+originalPath: .tmp-workos-clone/packages/docs/content/authkit/branding.mdx
 ---
 
 ## Introduction
@@ -14,7 +14,8 @@ The brand editor allows you to:
 - Upload logos and favicons
 - Set brand colors for buttons, links, and backgrounds
 - Manage visual properties such as page layouts, corner radius, and dark mode appearance
-- Include custom ad copy, images, and links to your app’s terms-of-service and privacy policy
+- Include custom copy, images, and links to your app’s terms-of-service and privacy policy
+- Preview auth screens and emails in various languages, and translate custom text into every supported locale
 
 The AuthKit preview will update in real-time as you make changes and accurately reflect the available authentication methods, giving you a clear picture of the authentication experience with AuthKit.
 
@@ -32,6 +33,12 @@ The corner radius applied to UI elements can also be configured; a lower value w
 
 ![Appearance options highlighted in the branding editor](https://images.workoscdn.com/images/3465072a-87a2-46cc-8577-4e9d4213009a.png?auto=format&fit=clip&q=50)
 
+## Font Family
+
+You can customize the font family used across AuthKit pages to match your brand's typography. The font family selector allows you to choose from a wide variety of Google Fonts to align with your product's brand. Only Google Fonts are supported for font family customization. This ensures optimal loading performance and reliability across all devices and browsers.
+
+![Font family options in the branding editor](https://images.workoscdn.com/images/4db463c8-4eb6-414d-801b-e7460407b238.png?auto=format&fit=clip&q=80)
+
 ## Assets
 
 You can upload custom brand assets to display in AuthKit, transactional emails, and the [Admin Portal](/admin-portal).
@@ -63,6 +70,14 @@ Other colors used in the UI, like the focus outline, hover styles, or borders, a
 
 ![Color options in the branding editor](https://images.workoscdn.com/images/b6a2eb40-2510-4e54-bdca-0c91953fb84d.png?auto=format&fit=clip&q=50)
 
+## Localization
+
+You can preview how your auth pages and emails appear in various different languages. AuthKit is [localized](/authkit/hosted-ui/localization) in many languages by default, and users are served in their preferred language automatically.
+
+To preview your brand in different languages, use the language picker in the AuthKit preview pane.
+
+![A preview of a user-facing email, translated in Spanish](https://images.workoscdn.com/images/663ee483-a14c-420b-9ba5-5c4c1f277b2c.png?auto=format&fit=clip&q=50)
+
 ## Copy
 
 The page title and alternate action link text on AuthKit pages can be customized to fit your brand’s tone of voice. They can be edited directly inside the AuthKit preview pane.
@@ -75,6 +90,8 @@ Start by selecting the page you want to edit. Then, click on the text you want t
 
 ![Text customization highlighted in the branding editor](https://images.workoscdn.com/images/07734ffb-c639-4abd-8d99-bd1feb9d5eda.png?auto=format&fit=clip&q=50)
 
+When you edit copy in English, it automatically gets translated into [every supported language](/authkit/hosted-ui/localization). A loading indicator appears next to the language picker during this process. After you save, your users will be served the translation that closest matches their locale.
+
 ## Page settings
 
 AuthKit pages can optionally display a link to your app’s privacy policy and/or terms-of-service. The link will then appear below the authentication form.
@@ -99,6 +116,8 @@ To enable this feature, select the page you want to customize. Then, select the
 
 Click on the secondary column from the preview pane. This will open a dialog where you can enter your HTML and CSS.
 
+> Note: content in the content panel will not automatically be [localized](/authkit/hosted-ui/localization).
+
 ![Custom code editor dialog in the branding editor](https://images.workoscdn.com/images/e0c512c9-dee0-470b-aa55-7d89c1b44a5c.png?auto=format&fit=clip&q=80)
 
 ### Custom code details and limitations
@@ -141,3 +160,202 @@ h1 {
   color: var(--primary-color);
 }
 ```
+
+## Last used sign-in badge
+
+AuthKit sign-in pages can optionally display a _Last used_ badge on an authentication method. This will indicate the most recent sign-in method for the user. The badge is shown by default and only shown when multiple sign-in methods are available.
+
+![AuthKit Last used sign-in badge](https://images.workoscdn.com/images/2f0e3778-08f3-4eb4-b590-0b39ff92e0d7.png?auto=format&fit=clip&q=50)
+
+## Custom CSS
+
+For more granular control over AuthKit branding, element styles can be overridden using custom CSS. Custom CSS applies globally across all AuthKit pages to ensure consistency across the entire authentication experience. It does not affect emails or Admin Portal.
+
+> AuthKit is powered by [Radix](https://www.radix-ui.com/) which has built-in accessibility and dark mode. If overriding styles, please make sure to test thoroughly, especially if removing original element styles.
+
+![AuthKit Custom CSS in the brand editor](https://images.workoscdn.com/images/0f48c7f3-b99c-417a-bee9-2e54780515df.png?auto=format&fit=clip&q=80)
+
+### Customize a specific page
+
+Target specific pages using the `data-hak-page` attribute selector:
+
+```css
+.ak-Header {
+  /* focus-start */
+  [data-hak-page='sign-up'] & {
+    .ak-Heading {
+      font-size: 3rem;
+      line-height: 1;
+    }
+  }
+  /* focus-end */
+}
+```
+
+- #### List of all available pages
+
+  **`sign-in`**
+  : Main sign-in page
+
+  **`sign-in/password`**
+  : Password-based sign-in
+
+  **`sign-in/passkey/enroll`**
+  : Passkey enrollment during sign-in
+
+  **`sign-up`**
+  : Main signup page
+
+  **`sign-up/password`**
+  : Password-based signup
+
+  **`sign-up/passkey`**
+  : Passkey-based signup
+
+  **`sign-up/magic-auth`**
+  : Magic link signup
+
+  **`sign-up/registration`**
+  : Custom registration form
+
+  **`oauth`**
+  : OAuth provider selection
+
+  **`magic-code`**
+  : Magic code verification
+
+  **`magic-code/send`**
+  : Magic code request form
+
+  **`mfa/enrollment`**
+  : MFA setup/enrollment
+
+  **`mfa/verification`**
+  : MFA code verification
+
+  **`email-verification`**
+  : Email verification page
+
+  **`radar-challenge`**
+  : Fraud detection challenge
+
+  **`radar-challenge/send`**
+  : Phone number input for SMS challenge
+
+  **`radar-challenge/verify`**
+  : SMS verification code input
+
+  **`invite`**
+  : Invitation acceptance page
+
+  **`reset-password`**
+  : Password reset flow
+
+  **`organization-selection`**
+  : Organization picker
+
+  **`device`**
+  : Device activation page
+
+  **`device/success`**
+  : Successful device connection
+
+  **`device/denied`**
+  : Device connection denied
+
+  **`application-authorization`**
+  : App consent/authorization page
+
+  **`default-redirect`**
+  : Default redirect after successful auth
+
+  **`not-found`**
+  : 404 error page
+
+  **`auth-disabled`**
+  : Authentication disabled message
+
+### Light and dark theme
+
+Use the [light-dark](https://developer.mozilla.org/en-US/docs/Web/CSS/color_value/light-dark) CSS function to easily target both light and dark themes with a single declaration:
+
+```css
+.ak-PrimaryButton {
+  /* focus-start */
+  color: light-dark(#333333, #f0f0f0);
+  /* focus-end */
+}
+```
+
+For more control, target the parent theme selectors directly:
+
+```css
+.ak-Background {
+  /* focus-start */
+  .dark-theme & {
+    background: linear-gradient(0deg, #333, #111);
+  }
+
+  .light-theme & {
+    background: linear-gradient(0deg, #fff, #ccc);
+  }
+  /* focus-end */
+}
+```
+
+> Media queries targeting `prefers-color-scheme` are not supported – use only the `.dark-theme` and `.light-theme` selectors.
+
+### Nested selectors
+
+AuthKit provides intelligent autocomplete support for CSS selectors. When you type a period (`.`) in the custom CSS editor, a popover will automatically appear showing available nested selectors for AuthKit elements, making it easier to target specific components and their child elements.
+
+![Nested CSS selectors](https://images.workoscdn.com/images/e8e41033-9e08-40c5-bfc9-0e223b1bd890.png?auto=format&fit=clip&q=80)
+
+### Examples
+
+#### Custom background image
+
+You can use external images as background images by specifying the URL in the `background-image` property.
+
+```css
+.ak-Background {
+  /* focus-start */
+  background-image: url('https://i.imgur.com/HO2EBgR.jpeg');
+  background-size: cover;
+  /* focus-end */
+}
+```
+
+#### Reorder OAuth buttons
+
+You can target an individual provider button by its `data-method` attribute.
+
+```css
+.ak-AuthButton {
+  /* focus-start */
+  /* Display Microsoft OAuth button first */
+  &[data-method='microsoft'] {
+    order: -1;
+  }
+  /* focus-end */
+}
+```
+
+#### Adding custom text
+
+Use CSS pseudo-elements to add custom text content.
+
+Custom text content in CSS cannot be [localized](/authkit/hosted-ui/localization). To learn how to automatically localize the text of your custom headings and links, read the [Copy](/authkit/branding/copy) section.
+
+```css
+.ak-Header {
+  /* focus-start */
+  &::after {
+    content: 'Sub heading';
+    display: block;
+  }
+  /* focus-end */
+}
+```
+
+> Some elements may already style the `::before` and `::after` pseudo-elements, so test your changes carefully.

package/.docs/organized/docs/authkit/cli-auth.mdx

@@ -0,0 +1,76 @@
+---
+title: CLI Auth
+description: Quickly add authentication to your command-line application.
+showNextPage: true
+originalPath: .tmp-workos-clone/packages/docs/content/authkit/cli-auth.mdx
+---
+
+## Introduction
+
+CLI Auth enables your command-line applications to authenticate users through the web via your WorkOS app. Based on the [OAuth 2.0 Device Authorization Flow](https://datatracker.ietf.org/doc/html/rfc8628), this flow is optimized for devices that lack a web browser or have limited input capabilities.
+
+With CLI Auth, your command-line app requests a device authorization from WorkOS, which includes a code for the user and a code for your app. After the user confirms the code, your app can exchanges its device code for tokens.
+
+## (1) Request device authorization
+
+To begin the authentication flow, your CLI application makes a request to the `/authorize/device` endpoint to obtain the necessary codes and URLs for user authentication.
+
+<CodeBlock>
+  <CodeBlockTab title="Request" file="device-authorization-request" />
+  <CodeBlockTab title="Response" file="device-authorization-response" />
+</CodeBlock>
+
+After you get a response, your app can provide next steps to the user.
+
+![Screenshot of a command-line application showing login information](https://images.workoscdn.com/images/89680848-5c40-4ba1-860f-a7212cfbb47b.png?auto=format&fit=clip&q=50)
+
+Your application should display the `user_code` from the response, along with the `verification_uri` in the terminal. If you offer the ability to open in a browser easily like in this screenshot, we suggest using the `verification_uri_complete` for that.
+
+Never display the `device_code` to the user. That is only for the device to poll the token endpoint.
+
+## (2) User confirms the code
+
+Next the user needs to confirm the code in their browser.
+
+### (A) Manual code entry
+
+If the user navigates to the `verification_uri`, they'll be presented with a form to enter the code manually. If they are not logged in they'll be prompted to do that first and then returned to the code entry screen.
+
+![Screenshot of the manual-code-entry form in AuthKit](https://images.workoscdn.com/images/03c1961a-547a-4886-bb9a-2f080dd31ca9.png?auto=format&fit=clip&q=50)
+
+### (B) One-click confirmation
+
+If the user goes to the `verification_uri_complete`, (for example, `https://<authkit_domain>/device?user_code=ABCD-EFGH`, they'll instead need to confirm that the code matches what is displayed in the terminal.
+
+![Screenshot of the pre-filled code-confirmation form in AuthKit](https://images.workoscdn.com/images/3e02f36c-0dea-4ff4-9dc5-a2f2fa964114.png?auto=format&fit=clip&q=50)
+
+## (3) Request tokens
+
+While the user is completing authentication in their browser, your CLI application should poll the token endpoint to check for authorization completion.
+
+Make requests to the token endpoint using `device_code` from the authorization response from step 1:
+
+<CodeBlock>
+  <CodeBlockTab title="Request" file="token-polling-request" />
+  <CodeBlockTab title="Response" file="token-polling-response" />
+</CodeBlock>
+
+### Polling best practices
+
+- Poll at the interval specified in the authorization response (every 5 seconds)
+- Respect `slow_down` errors by increasing your polling interval
+- Stop polling when you receive `access_denied` or `expired_token` errors
+- Implement a reasonable timeout to avoid infinite polling
+
+## Connect
+
+CLI Auth is available for [Connect](/authkit/connect/oauth) applications, allowing you and third-party developers to build CLI tools that integrate with your app's credentials.
+
+The flow is the same but uses Connect endpoints:
+
+- **Authorization**: `https://<authkit_domain>/oauth2/device_authorization`
+- **Token**: `https://<authkit_domain>/oauth2/token`
+
+Since command-line applications are distributed to end users, you should avoid embedding the client secret in the app. To make this work, set up your Connect app as a [_Public_ application](/authkit/connect/oauth/public-applications).
+
+Third-party Connect applications will require users to [grant consent](/authkit/connect/oauth/first-party-vs-third-party-applications) to the third-party app.

package/.docs/organized/docs/authkit/cli-installer.mdx

@@ -0,0 +1,157 @@
+---
+title: CLI Installer
+description: >-
+  Add AuthKit to your project in minutes with a single command. The WorkOS CLI
+  uses AI to detect your framework, install the right SDK, and write the
+  integration code automatically.
+showNextPage: true
+originalPath: .tmp-workos-clone/packages/docs/content/authkit/cli-installer.mdx
+---
+
+## Introduction {{ "visibility": "no-quick-nav" }}
+
+Run one command, the CLI handles the rest: framework detection, SDK installation, route creation, environment setup, and build validation. Your app goes from zero auth to full AuthKit integration in about two minutes.
+
+<CodeBlock>
+  <CodeBlockTab title="npx" file="cli-install-npx" />
+  <CodeBlockTab title="Global install" file="cli-install-npm-global" />
+</CodeBlock>
+
+```bash
+$ npx workos@latest install
+
+◆  Detected Next.js 15.3.1 (App Router)
+│
+◇  Opening browser for WorkOS authentication...
+│  Authenticated as nick@example.com
+│
+◇  Configuring your WorkOS dashboard...
+│  ✓ Redirect URI set to http://localhost:3000/callback
+│  ✓ Homepage URL set to http://localhost:3000
+│
+◇  Installing @workos-inc/authkit-nextjs...
+│  ✓ Package installed
+│
+◇  Analyzing project structure...
+│  ✓ Created /app/callback/route.ts
+│  ✓ Created proxy.ts
+│  ✓ Updated /app/layout.tsx with AuthKitProvider
+│  ✓ Created .env.local
+│
+◇  Validating integration...
+│  ✓ Build completed successfully
+│
+◆  AuthKit is ready. Run `npm run dev` to get started.
+```
+
+> Prefer to configure things yourself? Follow the [Quick Start](/authkit) guide instead.
+
+---
+
+## What the CLI handles
+
+The CLI takes care of everything you would normally do manually:
+
+1. **Detects your framework** — Identifies your framework and version from your project's dependencies and file structure
+2. **Authenticates your account** — Opens your browser for secure WorkOS sign-in
+3. **Configures your dashboard** — Sets redirect URIs, CORS origins, and homepage URL automatically
+4. **Installs the right SDK** — Adds the correct AuthKit package for your framework
+5. **Analyzes your project** — Reads your project structure to understand routing, existing middleware, and configuration
+6. **Creates routes and middleware** — Writes OAuth callback routes, auth middleware/proxy, and provider wrappers
+7. **Sets up environment variables** — Writes API keys and configuration to `.env.local`
+8. **Validates the integration** — Runs your build to verify everything compiles without errors
+
+The CLI understands framework-specific nuances — like Next.js App Router vs Pages Router, Vite vs Create React App, and React Router nuances — and generates the appropriate code for your setup. If you have existing middleware or configuration, it composes with it rather than replacing it.
+
+---
+
+## Supported frameworks
+
+| Framework               | SDK                                  |
+| ----------------------- | ------------------------------------ |
+| **Next.js**             | `@workos-inc/authkit-nextjs`         |
+| **React**               | `@workos-inc/authkit-react`          |
+| **React Router**        | `@workos-inc/authkit-react-router`   |
+| **TanStack Start**      | `@workos-inc/authkit-tanstack-start` |
+| **SvelteKit**           | `@workos-inc/authkit-sveltekit`      |
+| **Node.js / Express**   | `@workos-inc/node`                   |
+| **Vanilla JS**          | `workos`                             |
+| **Python / Django**     | `workos` (pip)                       |
+| **Ruby / Rails**        | `workos` (gem)                       |
+| **Go**                  | `github.com/workos/workos-go`        |
+| **PHP**                 | `workos/workos-php`                  |
+| **PHP / Laravel**       | `workos/workos-php-laravel`          |
+| **.NET / ASP.NET Core** | `WorkOS.net`                         |
+| **Kotlin**              | `com.workos:workos-kotlin`           |
+| **Elixir / Phoenix**    | `workos` (hex)                       |
+
+---
+
+## How the installer works
+
+The CLI uses an AI agent with restricted permissions to integrate AuthKit into your project:
+
+1. **Local analysis** — The agent reads your project files locally to detect frameworks and understand your project structure.
+2. **Restricted execution** — The agent can only run a limited set of commands: package installation, builds, type-checking, and formatting. It cannot run arbitrary shell commands.
+3. **File modifications** — The agent creates and edits files in your project to set up the AuthKit integration. Use `git diff` after installation to review every change.
+4. **Dashboard configuration** — The CLI configures your WorkOS dashboard settings (redirect URIs, CORS) using your authenticated session.
+
+---
+
+## Prerequisites
+
+- Node.js 20+
+- A [WorkOS account](https://dashboard.workos.com)
+- A project using one of the [supported frameworks](#supported-frameworks)
+
+---
+
+## CLI options
+
+| Flag                   | Description                                                           |
+| ---------------------- | --------------------------------------------------------------------- |
+| `--integration <name>` | Skip auto-detection and specify your framework manually               |
+| `--redirect-uri <uri>` | Custom OAuth callback URI (default: `http://localhost:3000/callback`) |
+| `--no-validate`        | Skip post-install build validation                                    |
+| `--debug`              | Verbose logging for troubleshooting                                   |
+
+---
+
+## Troubleshooting
+
+### The CLI didn't detect my framework
+
+Use the `--integration` flag to specify your framework manually:
+
+```bash
+npx workos@latest install --integration nextjs
+```
+
+### Build validation failed
+
+Run the CLI with `--debug` for detailed output. Make sure your project builds cleanly before running the CLI — pre-existing build errors will cause validation to fail.
+
+```bash
+npx workos@latest install --debug
+```
+
+### I want to see what changed
+
+After the CLI completes, use `git diff` to review all the files it created or modified:
+
+```bash
+git diff
+```
+
+### Something else went wrong
+
+Run `workos doctor` to diagnose common issues. If the problem persists, [open an issue on GitHub](https://github.com/workos/cli/issues) with the output from `--debug` mode.
+
+---
+
+## What's next
+
+- [Sessions](/authkit/sessions) — Understand session management
+- [Branding](/authkit/branding) — Customize the AuthKit UI
+- [Example Apps](/authkit/example-apps) — View complete working examples
+- [Quick Start](/authkit) — Manual integration guide for full control

package/.docs/organized/docs/authkit/connect/m2m.mdx

@@ -0,0 +1,65 @@
+---
+title: M2M Applications
+description: Implement machine-to-machine authentication with WorkOS Connect.
+showNextPage: true
+originalPath: .tmp-workos-clone/packages/docs/content/authkit/connect/m2m.mdx
+---
+
+## Overview
+
+Machine-to-machine (M2M) applications are designed for use-cases where clients are other services, such as one of your customer's applications. M2M applications use the underlying `client_credentials` flow for authentication.
+
+M2M access tokens will contain an `org_id` claim which represents the third-party you are granting access to via the M2M application.
+
+> M2M applications can only be configured as third-party.
+
+M2M applications are one of two ways WorkOS enables you to issue credentials to your customers that they use to programmatically access your application. The other is [API keys](/authkit/api-keys). The [API Keys vs M2M Applications guide](https://workos.com/blog/api-keys-vs-m2m-applications) can help you decide which is best for your use case.
+
+## Common Use Cases
+
+M2M applications are commonly used to provide API access credentials to customers or partners, allowing them to programmatically access your APIs and integrate your services into their applications. They're also ideal for partner integrations that run server-to-server without user interaction, where you need to track and control access on a per-organization basis.
+
+## Receiving Tokens
+
+Machine-to-machine applications can use the `client_credentials` grant type with the [Token Endpoint](/reference/workos-connect/token) to obtain an `access_token` to authenticate calls to your API.
+
+<CodeBlock
+  title="Obtain access token"
+  file="connect-client-credentials-example"
+/>
+
+## Organization-Based Access Control
+
+M2M applications are always associated with a specific [Organization](/reference/organization), which represents the customer or partner. Since machine-to-machine applications are associated with a particular organization, issued access tokens contain an `org_id` claim that your application's API can use to control access.
+
+This association provides several benefits:
+
+1. **Scoped Access**: Access tokens contain an `org_id` claim that identifies which organization the client is acting on behalf of
+2. **Resource Isolation**: Your API can use the `org_id` to ensure clients only access resources they're authorized for
+3. **Audit Trail**: All API calls can be attributed to a specific organization for auditing purposes
+
+## Verifying Tokens
+
+Your application can verify the tokens sent by external M2M applications for the purpose of authenticating requests using the JWKS for your environment. The process is similar to validating the access token JWT provided by an AuthKit login.
+
+<CodeBlock>
+  <CodeBlockTab file="connect-access-token-verification.m2m" title="M2M" />
+</CodeBlock>
+
+In addition to fast stateless verification, you can use the [Token Introspection API](/reference/workos-connect/introspection) to synchronously check whether a token is still valid.
+
+## Configuration
+
+M2M applications require the following configuration:
+
+### Credentials
+
+M2M applications use the `client_id` and `client_secret` from a credential to authenticate to the [Connect APIs](/reference/workos-connect) using the client credentials flow.
+
+### Name and Description
+
+While not displayed to users (since M2M apps don't have user interaction), the name and description help you manage and identify different M2M applications in your dashboard.
+
+## Next Steps
+
+- [Connect API Reference](/reference/workos-connect) - Complete API documentation

package/.docs/organized/docs/authkit/connect/oauth.mdx

@@ -0,0 +1,88 @@
+---
+title: OAuth Applications
+description: >-
+  Integrate OAuth applications with WorkOS Connect for web and mobile
+  authentication.
+showNextPage: true
+originalPath: .tmp-workos-clone/packages/docs/content/authkit/connect/oauth.mdx
+---
+
+## Overview
+
+OAuth applications are designed for applications where the actor being authenticated is a [User](/reference/authkit/user). These include web applications, mobile, desktop, and CLI tools. OAuth applications use the underlying `authorization_code` OAuth flow which is supported by many libraries and frameworks out of the box.
+
+> For server-to-server requests from a third-party without user interaction, use [M2M applications](/authkit/connect/m2m) instead.
+
+## First-party vs Third-party Applications
+
+When creating OAuth applications, you choose the level of trust: first-party or third-party.
+
+### First-party applications
+
+Select first-party when the application is one that your team controls, such as supporting services that are deployed separately from your main application but still need access to your users' identities. Examples include community forums or customer support portals.
+
+### Third-party applications
+
+Select third-party when the application is one built by your customers or partners, but you do not directly control the integrating application. For this reason, you must also associate third-party applications with an [Organization](/reference/organization) that represents the customer or partner.
+
+A third-party OAuth application will generally have a "Sign in with [your application]" button on their login page, in the same way many sites have a "Sign in with Google" button, allowing you to offer similar functionality to your customers or partners. Unlike first-party applications, your users will be prompted in AuthKit to explicitly authorize the application before their identity is shared.
+
+![Screenshot of the application authorization screen in AuthKit.](https://images.workoscdn.com/images/afde561f-9378-4aa6-995c-cda8f3ec0a63.png)
+
+## Receiving Tokens
+
+After an application has been issued credentials from a Connect Application, it can receive identity and access tokens using the OAuth 2.0 `authorization_code` flow.
+
+Many OAuth and OIDC libraries support Connect applications out of the box, needing only configuration:
+
+<CodeBlock>
+  <CodeBlockTab file="connect-oauth-configuration.passport" title="Passport" />
+  <CodeBlockTab file="connect-oauth-configuration.omniauth" title="OmniAuth" />
+</CodeBlock>
+
+## Public Applications
+
+By default, OAuth applications are confidential and must authenticate with a client secret when exchanging authorization codes for tokens. However, certain types of applications cannot securely store client secrets, such as command-line tools or mobile applications.
+
+For these use cases, you can configure an OAuth application as **Public**. Public applications:
+
+- Cannot securely store client secrets
+- Must use [Proof Key for Code Exchange (PKCE)](https://datatracker.ietf.org/doc/html/rfc7636) in order to authenticate with the [Token Endpoint](/reference/workos-connect/token)
+
+OAuth applications can be set as _Public_ during creation in the WorkOS Dashboard.
+
+## Verifying Tokens
+
+Your application must verify the tokens sent by OAuth applications using the JWKS for your environment. User information in the token can be used to look up related resources and perform further access control checks.
+
+<CodeBlock>
+  <CodeBlockTab file="connect-access-token-verification.oauth" title="OAuth" />
+</CodeBlock>
+
+In addition to fast stateless verification, you can use the [Token Introspection API](/reference/workos-connect/introspection) to synchronously check whether a token is still valid.
+
+## Organization Access
+
+When a user who is a member of multiple Organizations authorizes an OAuth Application, they will be prompted to select one of their Organizations to grant access to. Or, if the user only has a single Organization membership, that Organization will be automatically selected.
+
+The selected Organization will be made available as the `org_id` claim in the issued [access token](/reference/workos-connect/token/authorization-code-grant/access-token), which your app can use to scope the access of requests made using the token.
+
+## Configuration
+
+OAuth applications require the following configuration:
+
+### Redirect URI
+
+This is the final location users will be redirected to after successful authentication. Clients should use the [Token Endpoint](/reference/workos-connect/token) to exchange the `code` for tokens at this location.
+
+### Name and Logo
+
+For third-party OAuth applications, the name and logo will be displayed to your users when they are prompted to authorize access. Both light and dark-mode logos are supported.
+
+### Credentials
+
+OAuth applications use the `client_id` and `client_secret` from a credential to authenticate to the [OAuth-based Connect APIs](/reference/workos-connect).
+
+## Next Steps
+
+- [Connect API Reference](/reference/workos-connect) - Complete API documentation