Repository navigation
Mcp oauth update - #12115
Mcp oauth update#12115
Conversation
For better readability
| MCP clients that support [MCP authorization](https://modelcontextprotocol.io/specification/2025-11-25/basic/authorization), such as Visual Studio Code, can sign in users at an OAuth 2.0 authorization server (identity provider) and send the access token to the MCP Server. To let clients discover where to obtain a token, set the following optional parameters in the `Create MCP Server` action: | ||
|
|
||
| * `AuthorizationServerUrl`: The issuer URL of the authorization server, for example, `https://login.microsoftonline.com/<tenant-id>/v2.0` for Microsoft Entra ID. This parameter requires an authentication microflow. | ||
| * `Scopes` (optional): The scopes that clients should request, separated by spaces, for example, `openid email`. This parameter requires `AuthorizationServerUrl`. Mendix recommends setting it, because without it, many clients request all scopes that the authorization server offers, which the authorization server may reject. |
There was a problem hiding this comment.
Hi @liamsommer-mx , i think this needs an improvement.
Can you confirm that the MCP module will check any scope configured here? Does the MCP Server also enforce these scopes when validating the access token?
For example, if mcp.access is configured here, will the MCP Server reject an otherwise valid access token that does not contain mcp.access?
I think the documentation should make this distinction explicit. Scopes advertised to clients (such as openid and email) and scopes enforced by the resource server are two different things.
As briefly discussed earl;ier this week. An API/Resource server/MCP should do following validations:
- JWT signature
- issuer (iss)
- audience (aud)
- expiration / validity (exp, eventueel nbf)
- required authorization claims, bijvoorbeeld scope (scope/scp) of roles/permissions
There was a problem hiding this comment.
I think you cherrypicked items from OIODC module to do:
- signature validation
- expiry/validity.
In the MCP configuration the developer would have to set: - expected issuer value
- expected audience value
- expected scope value
There was a problem hiding this comment.
If your implementation does all these validations, I would suggest for documentation:
"Scopes: The OAuth scopes that clients should request when obtaining an access token for this MCP Server. Configure scopes that represent access to the MCP Server or its capabilities, as defined by your authorization server. For example, an authorization server might define a scope such as "mymcp.access" Avoid using OpenID Connect scopes such as openid or email as required scopes for your MCP. You must register the scope value (e.g. "mymcp.access") at your IdP, which enables your IdP to make authorization decisions for access to your MCP server. "
There was a problem hiding this comment.
The MCP Server itself does not validate any scopes, this is up to the implementation of the auth. microflow. The MCP Server just advertises which scopes should be requested, because otherwise the client might request all from the auth server.
I did not know about the OpenID scope, but will add this.
There was a problem hiding this comment.
So the DecodeVerifyJWTPlainText action, that we recommend to use for checking the JWT, already checks iss, aud and exp. As we don't know what customers put in their scopes, we cannot say for sure what they need to check there. I will add another part that additional checks might be useful, e.g., on scopes.
|
|
||
| 1. Read the `Authorization` header from `System.HttpRequest`. If missing, return empty to initiate the client sign-in flow. | ||
| 2. Validate the token. Depending on the authorization server, you can do this in one of the following ways: | ||
| * Call the token introspection endpoint ([RFC 7662](https://datatracker.ietf.org/doc/html/rfc7662#section-2)) of the authorization server, for example, with a **Call REST service** activity. |
There was a problem hiding this comment.
Put this as a second option. I suggest
" In exceptional cases where case your IdP issues opaque tokens - i.e. not being a JWT - or when your IdP supports token revocation, you may want to call the token introspection endpoint (RFC 7662) of the authorization server, for example, with a Call REST service activity. In most scenarios this is not needed. Common IdP-technologies such as Entra ID, Okta, KeyCloak issue access tokens having the JWT profile."
| The authentication microflow runs for every request, including several requests when the client connects. If your microflow calls an external service, such as an introspection endpoint, consider the additional response time or implement custom logic for expiry state management. | ||
| {{% /alert %}} | ||
|
|
||
| The MCP client must be registered at the authorization server. Clients use [dynamic client registration](https://datatracker.ietf.org/doc/html/rfc7591) if the authorization server allows it. Otherwise, register the client at the authorization server and enter its client ID in the MCP client when asked. |
There was a problem hiding this comment.
I would suggest leaving out the remark about DCR. EntraID (used by 70% of our customers) does not support it. Also the OIDC SSI module does not support DCR yet.
I suggest:
"
The MCP client must be registered at the authorization server in order to obtain an Access Token. Typically this is done via manual client registration via your IdP's admin pages."
| * Call the token introspection endpoint ([RFC 7662](https://datatracker.ietf.org/doc/html/rfc7662#section-2)) of the authorization server, for example, with a **Call REST service** activity. | ||
| * Use the [OIDC SSO](/appstore/modules/oidc/) module, which supports validating tokens against the signing keys of the authorization server. This is required for authorization servers without an introspection endpoint, such as Microsoft Entra ID. For example use the `DecodeVerifyJWTPlainText` action to verify and get the JWT token. Note that the `APIAuthentication` action is currently not supported when called from the MCP Server module. | ||
| 3. Check that the token is active and not expired, and that the audience (`aud`) is the value that the authorization server issues for your MCP Server. Otherwise, your MCP Server accepts tokens that were issued for other applications. Based on your requirements, check other fields such as scopes or issuer. | ||
| 4. Return the `System.User` that belongs to the token, for example, by retrieving the user by name based on the `preferred_username` claim or creating a new user. |
There was a problem hiding this comment.
Does the MCP module create the user? Or is this up to the developer?
In any case, we need to add a reference to
https://docs.mendix.com/developerportal/deploy/implementing-user-metering/#user-classification
There was a problem hiding this comment.
No, that is part of the implementation of the auth. microflow. I can add a reference to this page.
No description provided.