This is very interesting! It looks like there's a config file [1] to set up username <- email,issuer associations. It looks like multiple identities (from different IdPs even) can access the same username, which is useful. There's also a config file for allowed IdPs [2] specifying the expected client IDs (btw, the docs here say all fixed duration options are for "24 hours" even 48h and 1week). This does seem to impose the limitation of exactly one client ID per IdP, which could complicate rotating client IDs.
Walking this through, given that OpenID Connect is specifically mentioned vs. bare OAuth2, I assume the ID token signatures are themselves verified by looking up ${ISSUER_URI}/.well-known/openid-configuration and following the jwks_uri found there. Is the JWKS response cached? Can it be pre-seeded and/or replaced with an offline copy?
> This does seem to impose the limitation of exactly one client ID per IdP, which could complicate rotating client IDs.
Thanks for asking this. I don't see any reason why you use the same IdP with two different Client-IDs. I haven't tested this, but it is doesn't work currently, I'd like to add it as a feature.
Your description of the protocol is spot on. OpenPubkey currently only works with ID Tokens.
>Is the JWKS response cached? Can it be pre-seeded and/or replaced with an offline copy?
Currently the JWKS response is not cached, but caching support is a feature we want to add.
What is the interest in a pre-seeded copy? Availability concerns?
I can think of two different uses for multiple client IDs with the same IdP: rotation as I mentioned already (e.g. if client secret leaks, although the secret is not used here), and for when there are multiple domains in use but the IdP clients are configured for internal use only. Both are pretty niche though. I think most IdPs will let you keep two client IDs active at the same time, so the rotation use case might already be covered.
As for pre-seeded/offline JWKS, yeah the biggest concern is around availability. The pre-seeded case would handle fresh VM setups before networking might be fully configured (though other auth methods as fallback would be good enough in most cases, I think). Completely offline JWKS would also be useful for machines with no outbound connectivity. Both use cases are again pretty niche though.
> As for pre-seeded/offline JWKS, yeah the biggest concern is around availability. The pre-seeded case would handle fresh VM setups before networking might be fully configured (though other auth methods as fallback would be good enough in most cases, I think).
I've been thinking about this as breakglass problem. How do you get into your server if your IDP is offline or you lose internet connectivity. My recommendation has been to have a standard public key SSH account breakglass.
A pre-seeded JWKS or alternative JWKS would let you have the same policy controls but allow you to create valid keys in extreme circumstances. I really like this.
Walking this through, given that OpenID Connect is specifically mentioned vs. bare OAuth2, I assume the ID token signatures are themselves verified by looking up ${ISSUER_URI}/.well-known/openid-configuration and following the jwks_uri found there. Is the JWKS response cached? Can it be pre-seeded and/or replaced with an offline copy?
[1]: https://github.com/openpubkey/opkssh/blob/main/README.md#etc...
[2]: https://github.com/openpubkey/opkssh/blob/main/README.md#etc...