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.
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.)
1. Issuing certificates is a lengthy process requiring key generation which is neither fast nor cheap at scale.
2. Working with x509 is a hell of a lot more cumbersome than working with JWTs.
3. The point wasn't that they're two different services; they're the same service from the perspective of the user but are internally disparate when deployed at scale.
1. Key generation is not required if you already have a key which is usable for this purpose. In this case, the server already has a public key since X.509 is already used for the server's certificate, so the certificate can be issued with the same public key. (If the client is issuing a certificate to the server, then the client's private key will be used to sign the certificate.)
2. I do not agree; I found X.509 to be better. I also think that DER is a better format than JSON (and that it does not require such things as escaping, base64 encoding, Unicode, etc). (I had made up a simpler usage for X.509 (more strict in some ways and less strict in other ways), although it is deliberately possible (without too much difficulty) to make a certificate which is compatible with both the normal usage and the simpler usage.)
Isn't this the whole point of SPIRE/SPIFFE?.
A workload can identify itself to a different trust domain as long as there's trust between the different domains and a policy that allows it.
Can someone provide an example of a practical use for this? It doesn't sound like a bad idea, I'm just struggling to imagine where it might be used.
I wrote a much more narrative version of what this is useful for here: https://aaronparecki.com/2025/05/12/27/enterprise-ready-mcp
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.
MCP is a great example, thank you
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.
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.)
1. Issuing certificates is a lengthy process requiring key generation which is neither fast nor cheap at scale.
2. Working with x509 is a hell of a lot more cumbersome than working with JWTs.
3. The point wasn't that they're two different services; they're the same service from the perspective of the user but are internally disparate when deployed at scale.
1. Key generation is not required if you already have a key which is usable for this purpose. In this case, the server already has a public key since X.509 is already used for the server's certificate, so the certificate can be issued with the same public key. (If the client is issuing a certificate to the server, then the client's private key will be used to sign the certificate.)
2. I do not agree; I found X.509 to be better. I also think that DER is a better format than JSON (and that it does not require such things as escaping, base64 encoding, Unicode, etc). (I had made up a simpler usage for X.509 (more strict in some ways and less strict in other ways), although it is deliberately possible (without too much difficulty) to make a certificate which is compatible with both the normal usage and the simpler usage.)
3. OK. I had not considered that.
Isn't this the whole point of SPIRE/SPIFFE?. A workload can identify itself to a different trust domain as long as there's trust between the different domains and a policy that allows it.
Appendix A: Use Cases offers several examples.