use jwks caching feature of openid_connect gem

[nov]

OpenIDConnect::ResponseObject::IdToken.decode now accepts OpenIDConnect::Discovery::Provider::Config::Response instead of key.
https://github.com/nov/openid_connect/blob/master/spec/openid_connect/response_object/id_token_spec.rb#L254-L300

then fetch JWK specified by the ID Token kid header from jwks_uri using JSON::JWK::Set::Fetcher.
https://github.com/nov/openid_connect/blob/master/lib/openid_connect/response_object/id_token.rb#L70-L73
https://github.com/nov/openid_connect/blob/master/lib/openid_connect/discovery/provider/config/response.rb#L90-L93

and JSON::JWK::Set::Fetcher has JWKS caching feature.
https://github.com/nov/json-jwt/wiki/JWK-Set#fetching

so, once omniauth_openid_connect gem users specify like this, this gem start caching JWKS by kid.

JSON::JWK::Set::Fetcher.cache = Rails.cache

ps.
you might want to support caching option via omniauth config?

config.omniauth :openid_connect, {
  issuer: 'https://idp.example.com',
  discovery: true,
  jwks_cacher: Rails.cache,
  client_options: {..}
}

[timpeat]

Nice!

[stanhu]

@nov In #134, I'm fixing how this gem handles HS256 signatures. I'm wondering if you see any issues with the approach there.

I was actually just looking at the changes made in the openid-connect gem in https://github.com/omniauth/omniauth_openid_connect/pull/134/files#r1027569274. I think that change assumes the JWT includes the kid when HS256 is used. It's been a while since I've played with Keycloak, but if I recall correctly it may not be included. I'll have to try this again.

[paulh-bb]

I wanted to check on the status of this. I know the PR is a bit out of date. Is there a plan to incorporate something like this? Caching the public keys with a configurable cache so we don't hit our jwks_uri on every verification would be very helpful for a project I am working on.