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.
junon•7mo 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•7mo 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.)
junon•7mo ago
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.
clvx•7mo ago
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.
zzo38computer•7mo ago
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.)
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.
bastawhiz•7mo ago
junon•7mo ago
This spec appears to outline how a user logged into one is automatically logged into another using cryptographically signed tokens.
zzo38computer•7mo ago
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.)
junon•7mo ago
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.
clvx•7mo ago
zzo38computer•7mo ago
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.
JimDabell•7mo ago
aaronpk•7mo ago
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.
bastawhiz•7mo ago