This looks pretty nice.
The idea around jwk_url is essentially what the discuss tutorial mimics but from the client side - it pulls the jwk_url from a settings file when updating the Slash GraphQL schema.
That experience makes me wonder if we need the key id in the Dgraph.Authorization JSON ?
I wonder if it’s better to grab the max age from the response (will this only work for firebase), or just require it in the settings, which would allow it to work in any devops process.
More generally, I think I need to understand how the keys and key ids are going to work. For this reason:
- a user logs into an app they have a valid JWT signed with key1
- while that session is still in process the app rotates it’s keys, so key2 is now the key being used to sign new JWTs
- somehow Slash knows about the key rotation
- what happens to the ongoing session with key1 ? That should still be valid unless the key used to sign it gets revoked. this also seems to say that.
So I wonder that the right approach is to read that jwk_url and accept any keys in there, except the revoked ones??
(… more broadly, I wonder if we should be accepting multiple keys all round??? e.g. if I’m doing key rotation without the jwk_url, then I’d want the current and next keys … probably leave this till someone asks though)
This will happen anyway, right? Even if I upload exactly the same schema as is in the system, everything gets refreshed. That would allow me to have a devops procedure that rotates some keys and then pings Slash to let it know to refresh from the jwk_url.
So I think there’s two possible valid processes here: one is refetch based on a timer, the other is refetch on schema being touched.
(Side note: I don’t think we should be supporting any identity provers in particular. I should be a general mechanism that works nicely with the given providers, but also works in all sorts of other curcumstances.)