It isn't exclusive to MCP, it applies to any regular OAuth connection between apps under the same enterprise IdP too, but MCP is a topical example at the moment.
junon 7 hours ago [-]
In big systems it's often the case, for better or worse, that two systems don't share a connection to a central auth server.
This spec appears to outline how a user logged into one is automatically logged into another using cryptographically signed tokens.
zzo38computer 6 hours ago [-]
Is that necessary?
For one thing, just because you are logged into one does not mean that you intend to be logged into other one also.
For another thing, it can be done by X.509; if there is a certificate that both systems allow for authentication, then the ones that are issued by that certificate can also be used by the other system, too.
A third thing is that partial delegation of authorization is also possible by X.509, and this can also be used to act on the user's behalf (which seems to also be mentioned in the article). The way that this would work is as follows:
1. The client uses a certificate previously issued to them to issue a certificate to the server (containing the server's public key, which the client already knows because the server also has a X.509 certificate). This certificate will contain an extension to specify the authorization.
2. The server then acts as a client, using the issued certificate for authentication, to another server.
3. The another server verifies the certificate chain, and grants the authorization according to the interaction of the authorizations permitted by each certificate in the chain (i.e. the operation must be authorized by each certificate in the chain in order to be authorized by the chain).
(Doing something like the fine-grained personal access tokens of GitHub would be similar except that the client issues a certificate to themself instead of to another server. You can also issue a certificate to yourself without limiting the permissions, e.g. in case you want to store the private key of the first certificate on a separate computer that is not connected to the internet, to be less likely to be compromised.)
It isn't exclusive to MCP, it applies to any regular OAuth connection between apps under the same enterprise IdP too, but MCP is a topical example at the moment.
This spec appears to outline how a user logged into one is automatically logged into another using cryptographically signed tokens.
For one thing, just because you are logged into one does not mean that you intend to be logged into other one also.
For another thing, it can be done by X.509; if there is a certificate that both systems allow for authentication, then the ones that are issued by that certificate can also be used by the other system, too.
A third thing is that partial delegation of authorization is also possible by X.509, and this can also be used to act on the user's behalf (which seems to also be mentioned in the article). The way that this would work is as follows:
1. The client uses a certificate previously issued to them to issue a certificate to the server (containing the server's public key, which the client already knows because the server also has a X.509 certificate). This certificate will contain an extension to specify the authorization.
2. The server then acts as a client, using the issued certificate for authentication, to another server.
3. The another server verifies the certificate chain, and grants the authorization according to the interaction of the authorizations permitted by each certificate in the chain (i.e. the operation must be authorized by each certificate in the chain in order to be authorized by the chain).
(Doing something like the fine-grained personal access tokens of GitHub would be similar except that the client issues a certificate to themself instead of to another server. You can also issue a certificate to yourself without limiting the permissions, e.g. in case you want to store the private key of the first certificate on a separate computer that is not connected to the internet, to be less likely to be compromised.)