Auth Providers
Configure a delegated OAuth provider for protected drio tools.
Use an auth provider when a drio app needs to call a protected system on behalf of the current user. The provider handles sign-in and consent. drio brokers the OAuth flow for compatible MCP clients and forwards the resulting access token to protected tools.
If your app only calls public APIs or shared service-account APIs, start with a static API key, bearer token, or no auth instead.
Choose A Provider
| Provider | Use When |
|---|---|
| Amazon Cognito | Your users already sign in through a Cognito user pool or Cognito Hosted UI. |
| Clerk | Your product uses Clerk as the OAuth or OIDC identity provider for users. |
| WorkOS | Your team uses WorkOS AuthKit or WorkOS Connect for B2B sign-in, SSO, or enterprise identity. |
What drio Needs
For delegated OAuth, drio needs the same core values from any provider:
- authorization endpoint
- token endpoint
- client ID
- client secret, when the provider requires one
- scopes
The provider must also allow the drio OAuth callback URL for the app. Add the callback URL shown in the drio auth config to the provider before testing sign in.
How This Fits MCP Auth
Provider setup is only one part of the MCP auth flow. For the full runtime model, including public discovery, protected tool challenges, and the OAuth bridge routes, see MCP Authentication In drio.