First of all let’s clarify we are aware that OIDC and oAuth2 are different protocols, albeit OIDC builds on the flows and mechanisms defined by oAuth2, and they also use different tokens, a JWT Identity Token used for OIDC, and a resource access token (possibly also JWT formatted, but not required to) for oAuth2; the first deals with the issue of federated authentication and the second deals with the issue of federated resource access authorisation).

Having said that, for this specific question it is more or less irrelevant what type of token we do have, as here we are interested in understanding the mechanism through which a client system trusts the legitimacy of a token (please understand client system as defined by the oAuth2 flow definition of client system plus any extra system capable of accepting those same digitally signed tokens).

For the sake of simplifying the argumentation, let’s assume that we are following an auth code grant flow. In this flow after the end-user has been redirected toward the Id/auth server, provided his credentials successfully, and being redirected back to the original "issuer client"; we can be sure that this “issuer client” can trust this token because it was obtained through a backchannel http request which provided the access code plus a client secret unknown to anybody else, so for this "issuer-client" it is trivial to trust this token. Let’s call this the “trivial case”.

Now let’s assume we have more client systems capable of potentially accepting this previously generated token -as long as that token is valid of course- (this would indeed be a form of SSO, because those systems are basically “bypassing” their end user login, by virtue of trusting this token previously generated by ANOTHER client). The question I have is how can those other clients (which didn’t issue the token initially as described previously on the trivial case) trust the legitimacy of this token?.

One way to solve the point in the above’s paragraph, would be for clients when presented with a token, to “ask” the id/auth provider if it indeed generated the token; but in different documentation & blogs I’ve seen it seems it is often the case that client systems usually accept the token without talking back to the Id/auth provider. How does this happen that the token is on itself enough for establishing trust? It is mentioned that the digital signature ensures nobody changed the token, but how can those systems know the token wasn’t generated by other -potentially malign- Identity/auth server?. Let’s say that we have a 2nd Identity/authorisation server that issues tokens identical in structure to the ones of the 1st one; under this situation, how do clients know that a token comes from auth server 1 and not auth server 2? For the clients to discern with 100% certainty that a token not only wasn’t changed, but also that was generated by the authority the clients know and trust, it seems as if the tokens need to have as part of their digital signature some piece of information which is specific to the Id/auth server that generated it and can’t be replicated by any impostor (and the clients knows how to decode).

So that is the gist of my question, how can “non issuer-clients” (when presented with a token), know without speaking to the Id/auth provider, that the received token not only wasn’t changed (for this the signature), but also know from which Id/auth provider they come from, and also how is it prevented that a “fake Id/auth provider” could generate almost identical otherwise perfect tokens.

Thanks in advance for any feedback, and sorry for my limited english, it is a complex topic and probably the question isn't formulated in the best way.

CodePudding user response：

The API's that receives the tokens usually queries the token providers /.well-known/openid-configuration endpoint to download the public signing keys.

then when the API receives an access token, it can use the public key from the provider that the API trusts, and verify that the access token is genuine and has not been modified.

Inside the token there is typically also an audience claim, that specifies who the intended target is for the token and also a claim describing who issued it.

So, there are many ways for a resource that receives an access token to verify that it is trustworthy.