add ssl_verify setting to be able to disable validating when using self signed certificates

[epugh]

If you have a self signed ssl certicate to do HTTPS in dev, then we need to be able to accept that.

[stanhu]

Thanks for the PR! The use case (self-signed certs in dev) is definitely real. I have a few concerns before we merge this.

The global-state problem

OpenIDConnect.http_config is process-global state stored as @@http_config ||= block across the openid_connect, rack-oauth2, swd, and webfinger gems. Because of the ||=, the block is set once and can never be changed or reset within the same process (there is no reset method on OpenIDConnect).

This has a subtle but serious consequence: in a multi-provider app (e.g., one provider with ssl_verify: false and another with the default true), whichever strategy initializes first wins. If the ssl_verify: false strategy runs first, SSL verification is disabled globally for every provider, every request, for the lifetime of the process—even providers that never set this option.

The @ssl_configured guard prevents calling http_config twice on the same instance, but does nothing to isolate providers from each other.

The general-SSL-options concern

ssl_verify covers one specific Faraday SSL field. Users also legitimately need:

• ssl.ca_file / ssl.ca_path — custom CA bundle (also common in enterprise environments)
• ssl.cert_store — custom OpenSSL cert store
• ssl.certificate / ssl.private_key — mTLS
• ssl.verify_mode, ssl.verify_depth, ssl.min_version, ssl.max_version

A more extensible approach would be to expose the Faraday config block directly:

option :http_config, nil  # e.g. proc { |f| f.ssl.verify = false }

def configure_http!
  return unless options.http_config.respond_to?(:call)
  ::OpenIDConnect.http_config(&options.http_config)
end

This still has the same global-state caveat, but it lets users configure anything Faraday supports without needing another PR per SSL field. The ssl_verify: false shortcut could then be kept as a convenience that constructs the right proc internally—or dropped in favor of the general option.

Missing coverage in issuer

configure_ssl_verification is called inside client and config, but issuer calls OpenIDConnect::Discovery::Provider.discover! directly before either of those methods is invoked (it fires first in request_phase and callback_phase). So on the very first login request, the WebFinger/SWD discovery call in issuer runs before SSL verification is disabled, meaning self-signed-cert failures can still happen there.

Suggestion

Rather than ssl_verify as a boolean client_option, I'd suggest:

1. A top-level option :http_config, nil that accepts a callable—this matches the underlying gem's own API, documents the global-state behavior explicitly, and covers all Faraday SSL/HTTP options.
2. Call it early—before issuer, config, and client are invoked—perhaps at the top of request_phase, callback_phase, and other_phase.
3. Document clearly that this is a process-global setting with a strong warning against setting ssl.verify = false in production.

Happy to collaborate on an alternative implementation if that direction sounds good.

[epugh]

Happy to collaborate on an alternative implementation if that direction sounds good.

I think what you are suggesting makes a LOT of sense. This is where my rather shallow understanding of A) the domain, and B) the code, comes through!

So, I'd love to see a PR from you and test it out with Quepid?!