I was decoding a JWT token via jwt.io (in the Debugger section) to see Headers, Payload. Surprisingly, it also verified, and I could see it (jwt.io debugger) is able to retrieve
The token contains the issuer (iss) of the token and the key id (kid), which identifies the public key that is needed to verify the signature With this information, jwt.io can find the public key in form of a JWK (JSON Web Key) on a JWKS endpoint (/.well-known/jwks.json), to verify the token. A JWKS (JSON Web Key Set) contains an array of JWKs, the link shows an example.
According to the cognito documentation, this mechanism is used, when you use the Amazon user pool to authenticate your users.
Providing keys via a jwks endpoint is a standard mechanism which is also used by other providers, e.g. Microsoft Azure.
I've been trying to understand that myself too. If you open developer tools and see requests made by jwt.io when you paste the token in the debugger page you'll see it makes additional requests.
In my token the iss was:
"iss": "http://localhost:8080/auth/realms/myrealm"
hence jwt.io added the standard path /.well-known/openid-configuration
and made XHR request to
http://localhost:8080/auth/realms/myrealm/.well-known/openid-configuration
Where it found a lot of information in json and among them there was jwks_uri
{
...
"jwks_uri": "http://localhost:8080/auth/realms/myrealm/protocol/openid-connect/certs",
...
}
And then there was another XHR request to the above url and response was jwks. Having that public key the jwt.io could verify the token. At least that's what I think happens.