You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: src/content/docs/agents/model-context-protocol/authorization.mdx
+13-5Lines changed: 13 additions & 5 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -124,7 +124,7 @@ Read the docs for the [Workers oAuth Provider Library](https://github.com/cloudf
124
124
125
125
### (3) Bring your own OAuth Provider
126
126
127
-
If your application already implements an OAuth Provider itself, or you use [Stytch](https://stytch.com/), [Auth0](https://auth0.com/), [WorkOS](https://workos.com/), or authorization-as-a-service provider, you can use this in the same way that you would use a third-party OAuth provider, described above in (2).
127
+
If your application already implements an OAuth Provider itself, or you use authorization-as-a-service provider, you can use this in the same way that you would use a third-party OAuth provider, described above in (2).
128
128
129
129
You can use the auth provider to:
130
130
- Allow users to authenticate to your MCP server through email, social logins, SSO (single sign-on), and MFA (multi-factor authentication).
@@ -133,6 +133,7 @@ You can use the auth provider to:
133
133
- Enforce the permissions so that agents can only invoke permitted tools.
134
134
135
135
#### Stytch
136
+
136
137
Get started with a [remote MCP server that uses Stytch](https://stytch.com/docs/guides/connected-apps/mcp-servers) to allow users to sign in with email, Google login or enterprise SSO and authorize their AI agent to view and manage their company's OKRs on their behalf. Stytch will handle restricting the scopes granted to the AI agent based on the user's role and permissions within their organization. When authorizing the MCP Client, each user will see a consent page that outlines the permissions that the agent is requesting that they are able to grant based on their role.
137
138
138
139
[](https://deploy.workers.cloudflare.com/?url=https://github.com/cloudflare/ai/tree/main/demos/mcp-stytch-b2b-okr-manager)
@@ -142,6 +143,7 @@ For more consumer use cases, deploy a remote MCP server for a To Do app that use
142
143
[](https://deploy.workers.cloudflare.com/?url=https://github.com/cloudflare/ai/tree/main/demos/mcp-stytch-consumer-todo-list)
143
144
144
145
#### Auth0
146
+
145
147
Get started with a remote MCP server that uses Auth0 to authenticate users through email, social logins, or enterprise SSO to interact with their todos and personal data through AI agents. The MCP server securely connects to API endpoints on behalf of users, showing exactly which resources the agent will be able to access once it gets consent from the user. In this implementation, access tokens are automatically refreshed during long running interactions.
146
148
147
149
To set it up, first deploy the protected API endpoint:
@@ -158,6 +160,12 @@ Get started with a remote MCP server that uses WorkOS's AuthKit to authenticate
158
160
159
161
[](https://deploy.workers.cloudflare.com/?url=https://github.com/cloudflare/ai/tree/main/demos/remote-mcp-authkit)
160
162
163
+
#### Descope
164
+
165
+
Get started with a remote MCP server that uses [Descope](https://www.descope.com/) Inbound Apps to authenticate and authorize users (for example, email, social login, SSO) to interact with their data through AI agents. Leverage Descope custom scopes to define and manage permissions for more fine-grained control.
166
+
167
+
[](https://deploy.workers.cloudflare.com/?url=https://github.com/cloudflare/ai/tree/main/demos/remote-mcp-server-descope-auth)
168
+
161
169
## Using Authentication Context in Your MCP Server
162
170
163
171
When a user authenticates to your MCP server through Cloudflare's OAuth Provider, their identity information and tokens are made available through the `props` parameter.
@@ -196,7 +204,7 @@ function requirePermission(permission, handler) {
196
204
status:403
197
205
};
198
206
}
199
-
207
+
200
208
// If permission check passes, execute the handler
201
209
returnhandler(request, context);
202
210
};
@@ -208,7 +216,7 @@ async init() {
208
216
this.server.tool("basicTool", "Available to all users", {}, async () => {
209
217
// Implementation for all users
210
218
});
211
-
219
+
212
220
// Protected tool using the permission wrapper
213
221
this.server.tool(
214
222
"adminAction",
@@ -221,7 +229,7 @@ async init() {
221
229
};
222
230
})
223
231
);
224
-
232
+
225
233
// Conditionally register tools based on user permissions
226
234
if (this.props.permissions?.includes("special_feature")) {
0 commit comments