Add Sign-In For Protected Systems

Use WorkOS when your drio app needs per-user access to protected data or workflows.

This page is the bridge between the business owner of the app and the technical team that reviews authentication. If your app only uses public content or shared API access, you can usually skip this page.

When You Need This

Use an external auth flow when the app should act on behalf of the signed-in user. Common examples:

showing CRM, billing, or support data tied to the current user
accessing internal systems that require user-level permissions
connecting to protected customer or employee data

When You Probably Do Not Need This

the app only uses public website or help center content
all users should see the same shared data
a service account is enough for the use case

What GTM Owners Should Confirm First

which systems the app needs to reach
whether each user should see their own data or shared team data
who owns the auth domain and OAuth provider setup internally
what the minimum useful scope is for the first version

Recommended Pattern

The common setup is:

drio hosts the MCP endpoint for the app
your team exposes an auth server that clients can discover
WorkOS handles sign-in and consent on that auth server
that auth server owns the callback and token exchange
protected tools validate bearer tokens before calling the upstream API

What matters at the product level

The important business question is simple: should the app know who the user is before it calls the connected system?

If yes, plan for an authentication handoff early. It affects rollout, internal review, and which clients can be used smoothly.

What the technical team will implement

A companion auth server should expose:

/.well-known/oauth-protected-resource
/.well-known/oauth-authorization-server
POST /api/ext/auth/register
GET /api/ext/auth/authorize
GET /api/ext/auth/callback
POST /api/ext/auth/token

The MCP endpoint should challenge unauthenticated requests so compatible AI clients can launch the OAuth flow automatically.

End-To-End Sequence

Mermaid diagram source:

sequenceDiagram
  autonumber
  participant ChatGPT
  participant MCP as MCP Endpoint
  participant Auth as Auth Server
  participant WorkOS

  ChatGPT->>MCP: GET /.well-known/oauth-protected-resource
  MCP-->>ChatGPT: Protected resource metadata
  ChatGPT->>Auth: GET /.well-known/oauth-authorization-server
  Auth-->>ChatGPT: OAuth server metadata
  ChatGPT->>Auth: POST /api/ext/auth/register
  Auth-->>ChatGPT: Client registration response
  ChatGPT->>Auth: GET /api/ext/auth/authorize
  Auth->>WorkOS: Redirect for sign-in and consent
  WorkOS-->>Auth: Upstream authorization code callback
  Auth-->>ChatGPT: Redirect with auth-server code
  ChatGPT->>Auth: POST /api/ext/auth/token
  Auth-->>ChatGPT: access_token + refresh_token
  ChatGPT->>MCP: Tool call with Bearer token
  MCP-->>ChatGPT: Authenticated tool response

Handoff Checklist

Share these questions with your technical reviewer:

which routes will expose protected-resource and authorization-server metadata
how client registration, authorization, callback bridging, and token exchange will be handled
how bearer tokens will be validated in protected tool execution
what scopes are actually required for the first release