Add support for OIDC claim discovery

Problem

Saleor currently is trying to guess which claims are supported by IdPs as we can see here: https://github.com/saleor/saleor/blob/6b6c73f4acd47bad77b5c04f4aab8c0ec0d59d98/saleor/plugins/openid_connect/plugin.py#L245-L274

Whereas Saleor could directly ask the IdP instead using /.well-known/openid-configuration which is part of the OpenID Connect Discovery RFC: https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderConfigurationResponse

For example, instead of trying to guess whether the URL is Google, it could fetch /.well-known/openid-configuration and check whether offline_access claim is supported (https://accounts.google.com/.well-known/openid-configuration)

This removes the need for hard-coding the scopes, and instead allows Saleor to dynamically take decision no matter the platform (Okta, Auth0, Keycloak, Cognito, Entra ID, …)

Solution

As we currently require user to configure explicitly all URL (instead of using discovery), I suggest that we add a new field in the configuration: oidc_configuration_url which must point to https://<provider>/.well-known/openid-configuration (e.g., https://oidc.vercel.com/saleorcommerce/.well-known/openid-configuration or https://accounts.google.com/.well-known/openid-configuration). Alternatively we can call authlib.oidc.discovery.get_well_known_url(issuer) but as we currently require users to explicitly enter all URLs, this would be inconsistent.

Then, Saleor should fetch this URL (with a short (2, 2) timeout) every time it needs it (such as when Saleor needs to determine which claims are supported).

The response must be cached, a 1h TTLs should be sufficient. We can consider making it customizable in the Dashboard configuration (minimum value should always be 1 or 5 minutes to prevent abuse) - this could especially be handy for users testing or adjusting their OIDC configuration as it may cause .well-known/openid-configuration to return different responses (e.g., a sysadmin is configuring/enabling the email_verified claim or the offline claim in their IdP).

We should consider protecting against race-conditions when .well-known/openid-configuration is stale, we shouldn't have N clients fetching concurrently that page, instead we should have only 1 worker fetching it at a time if possible (through Stale-While-Revalidate pattern, e.g., https://www.kashif.app/stale-while-revalidate-cache [archive])

Discord Discussion Link

N/A

General Assumptions

N/A

API Changes

No response

Database Changes

No response

UML Diagrams

No response

To Do List

No response

Testing Requirements

No response