Thanks for the detailed comment.
It is not necessary to take key id in Dgraph.Authorization JSON. We fetch all the JWK’s from the jwk_url, then decode our JWT token. The decoded JWT token contains kid in its header in the case and we need to verify it against the signing key with the same kid from the fetched list of JWK’s.
This is the example header of the decoded JWT issued from One of the Identity Provider:
{
alg: "RS256",
typ: "JWT",
kid: "kiCD9MttZUa5IZRhmgj_n"
}.
When we just rotate the keys, the previous JWK is also present there, thus fetching JWKs from the jwk_url also fetches the previously used JWK. Any JWT which was signed by the previous key is still valid (as we have one of the JWK with exact same kid as in the decoded JWK). However, if we revoke the key, it gets removed from the jwk_url thereby making any token signed by it invalid.
Yeah, It should happen even if the same schema is being refreshed.
Both of these processes need to be incorporated because there could be two possible cases.
1- If the signing keys are rotated on regular intervals then the user shouldn’t bother about it. He just needs to convey to the server about the rotating nature of the keys.
2- If the user manually wants to change the rotating keys, then updating the schema should trigger that.
Parsing max-age from the response works only for firebase (as per my understanding).
Taking it in the settings is also a Good Idea.