undefined | Better HN

0 pointsEthanHeilman1y ago0 comments

> 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?

0 comments

2 comments · 1 top-level

kbolino1y ago· 1 in thread

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.

EthanHeilmanOP1y ago

> 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.

I created an issue to track this. Let me knof you want to do the implementation https://github.com/openpubkey/opkssh/issues/44

j / k navigate · click thread line to collapse