WorkOS
Configure WorkOS as a delegated OAuth provider for protected drio tools.
Use WorkOS when your team uses WorkOS User Management or AuthKit for sign-in, SSO, and enterprise identity.
WorkOS has two related setup paths:
- WorkOS Connect OAuth applications use your AuthKit domain with
/oauth2/authorizeand/oauth2/token. - WorkOS User Management/AuthKit application sign-in uses the WorkOS User Management authorization APIs.
For a drio delegated OAuth provider, use the OAuth application path when you want standard OAuth endpoints that an MCP client can authorize against.
What You Need From WorkOS
- your AuthKit domain, such as
https://your-subdomain.authkit.app - authorization endpoint
- token endpoint
- client ID
- client secret
- scopes
- the drio callback URL
WorkOS documents OAuth application setup in OAuth Applications. The authorize and token endpoints are documented in the WorkOS Connect API reference:
Configure The drio Preset
In drio, create a WorkOS OAuth auth config. For WorkOS Connect OAuth applications, use your AuthKit domain endpoints.
| drio Field | WorkOS Value |
|---|---|
| Authorization endpoint | https://YOUR_AUTHKIT_DOMAIN/oauth2/authorize |
| Token endpoint | https://YOUR_AUTHKIT_DOMAIN/oauth2/token |
| Client ID | WorkOS application client ID |
| Client secret | WorkOS application client secret |
| Scopes | openid, profile, email, offline_access |
Use offline_access only when the app needs refresh tokens. WorkOS documents
that refresh tokens are returned when the initial authorization request includes
the offline_access scope.
Configure Callback URLs In WorkOS
Add the drio callback URL shown in the auth config to the allowed callback URLs for the WorkOS application. WorkOS requires the redirect URI used in the authorization request to match an allowed redirect URI in the dashboard.
WorkOS also supports public applications for clients that cannot safely store a client secret. For server-side drio auth configs, use a confidential application with a client secret unless your implementation specifically requires a public PKCE-only client.
Test Sign-In
If sign-in fails, check:
- the WorkOS application allows the exact drio callback URL
- the client ID and client secret are from the same WorkOS environment
- the scopes in drio are allowed by the WorkOS application
- the AuthKit domain in drio matches the intended WorkOS environment
- the application type matches how you expect the token exchange to authenticate