Enable multiple providers

[yanasega]

Expected Behavior

Solution should support authentication via multiple providers and not only one, including support of multiple providers of the same type (i.e 2 different okta providers).

Current Behavior

Oauth2-proxy currently supports only 1 provider at a time (and all its provider related configuration is bound to it). Additionally, currently it is not trivial to ingest recurring structured configs (in our case providers) in an elegant way while supporting all possible ingestion methods.

Possible Solution

Tap into the big structural config refactoring (#532) to configure multiple providers in a YAML file and once provider is chosen pass it in a designated provider cookie through the chain.

Steps

1. Ingest providers via custom yaml loader and attach to main options:

- provider: okta
   provider_display_name: okta_1
   provider_ca_files:
     - file1
     - file2
- provider: azure
   provider_display_name: azure_1
...

2. Loop over each provider configuration info and perform validation on each, with the goal of creating a providers map[string]providers.Provider (instead of the single provider providers.Provider) - a map from provider display name to provider struct.
3. Load a template that supports multiple providers (sorted).
4. Initiate a proxy with provider cookie field and add support to each provider with its own session chain.
5. Once provider chosen, attach it to the provider cookie, and extract it from the map when provider related actions are needed.

Additional comments / Caveats

1. Provider display name must be a mandatory field to enable support of multiple providers of the same type.
2. Verify that suggested changes do not damage the s2s flows supported by OIDC (i.e https://medium.com/in-the-weeds/service-to-service-authentication-on-kubernetes-94dcb8216cdc) - haven't gotten the time to review this fully yet, so I'll better add this here.
3. skip-provider-button will be irrelevant in case more than 1 provider is configured.
4. Need to be careful dividing configs that are related to each provider and common configs between all providers (if there's any) - i.e how to handle provider-ca-files? one for each provider or general to all defined providers (used to define cert pool of http.DefaultClient))?
5. Open question - how Redis and Cookie stores need to support the provider cookie? one option is to add providerCookie to cookie store and somehow translate that into the ticket version on the Redis alternative..?

[JoelSpeed]

I am definitely up for supporting this feature, it's been asked for a few times in the past and hopefully shouldn't add too much extra complexity.

Some initial feedback on this proposal:

Ingest providers via custom yaml loader and attach to main options

I would like this to become part of the new AlphaOptions struct so that it can be loaded using the new alpha-config flag that is being added.

Also, I expect it to be a list in that so something like:

providers:
- type: azure
  ...
- type: oidc
  ...

Where we have provider specific options (I'd like to minimise this) but they should become substructs of the provider struct, so for example: (this is how we are doing it in the session storage so let's copy that pattern)

- type: azure
  azureConfig:
    tenant: foo

Loop over each provider configuration info and perform validation on each, with the goal of creating a providers map[string]providers.Provider (instead of the single provider providers.Provider) - a map from provider display name to provider struct.

I'd suggest adding an ID field as we have done in the Upstream so that there can be log friendly IDs and user friendly Display names that aren't necessarily the same.

Initiate a proxy with provider cookie field and add support to each provider with its own session chain.

Why does each provider need its own cookie? I would expect a user to only need to be logged in to one provider at a time and only need one session with OAuth2 Proxy.

If there are multiple cookied sessions, how do we determine which one the user wants to use to provide header information to the upstream?

Once provider chosen, attach it to the provider cookie, and extract it from the map when provider related actions are needed.

We will want to add a new field to the sessionstate that contains the provider ID, this will enable us to perform the required actions (such as refreshing, checking validity) when a session is being loaded rather than being created. If the provider ID cannot be found (eg someone updated the configuration), then the session load should fail and the user should be logged out (clear cookie/session).

Need to be careful dividing configs that are related to each provider and common configs between all providers (if there's any) - i.e how to handle provider-ca-files? one for each provider or general to all defined providers (used to define cert pool of http.DefaultClient))?

It may be good to gather a list of all the options that are currently affecting the providers and then we can discuss how we want the structure of the config to look, which can be dropped, which should be shared between all providers, which can be dropped as part of this refactor, etc.

Provider display name must be a mandatory field to enable support of multiple providers of the same type.

I think it would be better to have a mandatory ID field as in the Upstream object and leave the display name as optional

Verify that suggested changes do not damage the s2s flows supported by OIDC (i.e https://medium.com/in-the-weeds/service-to-service-authentication-on-kubernetes-94dcb8216cdc) - haven't gotten the time to review this fully yet, so I'll better add this here.

@NickMeves is working on a PR to streamline this process at the moment. From my understanding this should be able to be implemented without affecting this too much, apart from the need to configure multiple providers in the jwt session loading middleware, but it should be relatively trivial

Open question - how Redis and Cookie stores need to support the provider cookie? one option is to add providerCookie to cookie store and somehow translate that into the ticket version on the Redis alternative..?

If we stick to just one session per user and don't conflate that with multiple providers, this question goes away 😉

[NickMeves]

Where we have provider specific options (I'd like to minimise this) but they should become substructs of the provider struct, so for example: (this is how we are doing it in the session storage so let's copy that pattern)

@JoelSpeed I actually started a spike of cleaning up the OIDC provider & adding some features yesterday.

When I was working claim -> session extraction, I thought about the OIDC provider specific claim-name options that are OIDC only fields now.

I was thinking about making those global option on the ProviderData and making any providers that are compatible be have full default OIDC options & methods (claims + group extraction) at their disposal. I think Keycloak, Gitlab & Azure fall into this category?

Sounds like you are in favor of this route as well?

I branched off #869 so once that merged I'll get a draft PR up so this is easier to visualize.

[yanasega]

@JoelSpeed thank you for your comments. AlphaOptions + providerID + yaml structure sounds great.
I also have some follow up questions:

1. Session/provider cookie issue - My assumption for the need for multiple session chains comes from buildSessionChain function where I assumed each provider will have its own session loader since OIDCVerifier (which populates the session loader) is based on ClientId. It may look something like this:

func buildSessionChains(opts *options.Options, sessionStore sessionsapi.SessionStore, validator basic.Validator) map[string]alice.Chain {
	chains := make(map[string]alice.Chain)

	for _, p := range opts.Providers {
		chain := alice.New(middleware.NewScope())
		if p.SkipJwtBearerTokens {
			sessionLoaders := []middlewareapi.TokenToSessionLoader{}
			if opts.GetOIDCVerifier(p.ProviderName) != nil {
				sessionLoaders = append(sessionLoaders, middlewareapi.TokenToSessionLoader{
					Verifier:       opts.GetOIDCVerifier(p.ProviderName), //--->  func (o *Options) GetOIDCVerifier(n string) *oidc.IDTokenVerifier 
					TokenToSession: opts.GetProvider(p.ProviderName).CreateSessionStateFromBearerToken,
				})
			}

			for _, verifier := range opts.GetProviderJWTBearerVerifiers(p.ProviderName) {
				sessionLoaders = append(sessionLoaders, middlewareapi.TokenToSessionLoader{
					Verifier: verifier,
				})
			}

			chain = chain.Append(middleware.NewJwtSessionLoader(sessionLoaders))
		}

		if validator != nil {
			chain = chain.Append(middleware.NewBasicAuthSessionLoader(validator))
		}

		chain = chain.Append(middleware.NewStoredSessionLoader(&middleware.StoredSessionLoaderOptions{
			SessionStore:           sessionStore,
			RefreshPeriod:          opts.Cookie.Refresh,
			RefreshSessionIfNeeded: opts.GetProvider(p.ProviderName).RefreshSessionIfNeeded,
			ValidateSessionState:   opts.GetProvider(p.ProviderName).ValidateSessionState,
		}))
		chains[p.ProviderName] = chain
	}

	return chains
}

This assumption led me to suggest having a single provider cookie that will store only the chosen provider after user selects it. Based on the information from the cookie the correct session chain will be loaded, i.e something like this:

func (p *OAuthProxy) getAuthenticatedSession(rw http.ResponseWriter, req *http.Request) (*sessionsapi.SessionState, error) {
	var session *sessionsapi.SessionState
	cookieProvider, err := req.Cookie(p.CookieProviderName)
	...
	provider, err := encryption.ValidateProvider(cookieProvider)
	...
	getSession := p.sessionChains[provider].Then(http.HandlerFunc(func(rw http.ResponseWriter, req *http.Request) {
		session = middleware.GetRequestScope(req).Session
	}))
	getSession.ServeHTTP(rw, req)
...

Another usage of the same mechanism is in the callback:

func (p *OAuthProxy) OAuthCallback(rw http.ResponseWriter, req *http.Request) {
	...

	cookieProvider, err := req.Cookie(p.CookieProviderName)
...
	provider, err := encryption.ValidateProvider(cookieProvider)
...

	session, err := p.redeemCode(req.Context(), util.GetRequestHost(req), req.Form.Get("code"), provider)
	...

And then (providers is of type map[string]providers.Provider):

func (p *OAuthProxy) redeemCode(ctx context.Context, host, code string, provider string) (*sessionsapi.SessionState, error) {
	if code == "" {
		return nil, errors.New("missing code")
	}
	redirectURI := p.GetRedirectURI(host)
	s, err := p.providers[provider].Redeem(ctx, redirectURI, code)
	if err != nil {
		return nil, err
	}
	return s, nil
}

Is this what you meant by 'multiple cookied sessions', or were we out of sync? and more importantly - how can we redeem the session (assuming it will be stored in sessionstate) if we don't have the provider chosen beforehand (as extracted above directly from the cookie)?

2. An initial division of the provider configs to start the discussion:

Mandatory for each provider:
ClientID
ClientSecret
ProviderType
ProviderId (new)

Optional for each provider:
SkipJwtBearerTokens
ExtraJwtIssuers
ProviderName
ProviderCAFiles
InsecureOIDCSkipIssuerVerification
SkipOIDCDiscovery
OIDCJwksURL
LoginURL
RedeemURL
ProfileURL
ProtectedResource
ValidateURL
Scope
Prompt
ApprovalPrompt
AcrValues
ClientSecretFile
OIDCIssuerURL

Provider specific:
KeycloakGroup
AzureTenant
BitbucketTeam
BitbucketRepository
GitHubOrg
GitHubTeam
GitHubRepo
GitHubToken
GitHubUsers
GitLabGroup
GoogleGroups
GoogleAdminEmail
GoogleServiceAccountJSON
UserIDClaim
OIDCGroupsClaim
InsecureOIDCAllowUnverifiedEmail
PubJWKURL
JWTKey
JWTKeyFile

3. I will resurface the issue with ProviderCAFiles here for the benefit of others - currently if this parameter is used then the http default client will be populated with the ca pool built from these files, but now there are multiple providers and each can have it's own provider-ca-files. The suggested solution was:

I would recommend adding a new method to the request builder for this that sets the client to use if a non nil client is passed in. That way every time we use the request builder we can chain the WithClient to the client field in the provider, which would only be initialised if that provider config had its CA file set.

[JoelSpeed]

Session/provider cookie issue - My assumption for the need for multiple session chains comes from buildSessionChain function where I assumed each provider will have its own session loader since OIDCVerifier (which populates the session loader) is based on ClientId. It may look something like this:

Ignore for the moment this part of the code, @NickMeves is refactoring that bit quite a lot and removing some of this complexity. This section is about loading a session from headers instead of cookies. Cookies are what we need to focus on here.

This assumption led me to suggest having a single provider cookie that will store only the chosen provider after user selects it.

Having a single cookie will store only the chosen provider, but I think that's desirable? As a user, I would expect when allowing multiple providers, that the user being logged in to any of my providers is sufficient to allow them access no?

Is this what you meant by 'multiple cookied sessions', or were we out of sync? and more importantly - how can we redeem the session (assuming it will be stored in sessionstate) if we don't have the provider chosen beforehand (as extracted above directly from the cookie)?

I think we may not have been on the same page. It looks like you're creating a cookie which has the provider name in, then using that to check which provider? Could this information not be encoded into the state parameter during the oauth flow? Then put into the SessionState for looking up later?

The provider string in the map lookup of providers I would expect to come from the session itself when we are loading the cookied session, we can add a field to the session that includes which provider ID created the session.

An initial division of the provider configs to start the discussion:

Don't want to focus too much on this first as it might distract from the bigger picture, only thing I will say now is that the stuff related to ExtraJWTIssuers will likely be separate from the provider information, @NickMeves we don't need those options to be in each provider do we?

Final thing to say is that this is obviously going to be a major project, it would be preferable if we could somehow break down the work into smaller PRs to make some of this easier to review. I guess the first thing to do if we are taking that approach is the structure of the configuration and the conversion logic, that would allow us to settle that before we do the main implementation

[yanasega]

@JoelSpeed yes, you are right the provider configs are a bit jumping the gun..

The provider string in the map lookup of providers I would expect to come from the session itself when we are loading the cookied session, we can add a field to the session that includes which provider ID created the session.

Just to be sure I understand - you suggest passing the chosen provider in the state param i.e fmt.Sprintf("%v:%v:%v", nonce, redirect, provider) and then when extracting it back from the state in the callback saving it to the sessionsstate to facilitate validation etc.? If so, this also might depend on @NickMeves changes to session chain (specifically getAuthenticatedSession method that relays on the chain).

I guess the first thing to do if we are taking that approach is the structure of the configuration and the conversion logic, that would allow us to settle that before we do the main implementation

Great, so how should we proceed?
My understanding is, based on the transition of handling Upstreams in v6.1.0, that it's possible to create LegacyProvider in LegacyOptions and then in the conversion option just append the only provider into the providers option slice (and in the alpha-config flow just ingest the yaml structure you described above). One issue is that this is not really a standalone PR because the entire backend needs to support multiple providers for this to work.

[JoelSpeed]

Just to be sure I understand

Yeah that was my suggestion, I think that is the idiomatic place to put this information when performing an oauth2 flow

Have you got a link handy to the work Nick is doing? Would be good to have that linked into this conversation

My understanding is, based on the transition of handling Upstreams in v6.1.0, that it's possible to create LegacyProvider in LegacyOptions and then in the conversion option just append the only provider into the providers option slice (and in the alpha-config flow just ingest the yaml structure you described above). One issue is that this is not really a standalone PR because the entire backend needs to support multiple providers for this to work.

This is exactly how I would start yes.

• Create the new Provider struct and all of the new structs within it
• Create the LegacyProvider and conversion to the new struct
• Update the main package and validation package (this should be the only thing using the whole options struct) to configure the proxy based on the new struct (p.IssuerURL = opts.IssuerURL => p.IssuerURL = opts.Providers[0].IssuerURL)
  • The bulk of the work here is the validation of the structs, at present, all of the setup for the providers is done in validation.Validate, we should be able to repoint the options to the new structure without too much hassle I would have thought
• Create validation/migrate validation for the new provider struct as required (if there are options that can't be set together for example, or if the IDs can't be duplicated (see the upstream validation logic)).

I think if we take the approach of renaming things in the validation method we should be able to keep the logical changes to a minimum and focus the first part of the review on just the design of the structure of the configuration. All changes outside of that discussion should just be renaming, conversion logic and validation logic.

We could perhaps even divide some of that into smaller PRs if we wanted to, the first two steps could possibly be done without integrating into anything else, it could be done as additions only pretty much. If you were to extract the LegacyProvider struct but not add it to the LegacyOptions, you could add it to the Options struct initially and have it inlined there as is done with the Cookie struct. The old logic for loading should be able to handle it still

[yanasega]

Sounds good to me! I see that alpha options #907 is merged, I'll pull it to my branch and get started:)

Regarding ProviderID - I don't think we have an alternative of a unique ID like in Upstreams because there is nothing unique except the providerDisplayName and clientID (which doesn't sound so secure to use), any suggestions?

Regarding passing the provider in state param - I am still a bit uncertain about the behaviour in all the cases that are not the oauth2 flow (all flows that require getAuthenticatedSession: UserInfo, Proxy and AuthenticateOnly) - @NickMeves do you happen to have a link to your related work?
What I am worried about here is that the logic of extracting the session might be bound to provider logic (like now if we must use session chains) and then we will be stuck in a loop (need providerID to extract session->session holds the providerID->..).

[JoelSpeed]

Regarding ProviderID - I don't think we have an alternative of a unique ID like in Upstreams because there is nothing unique except the providerDisplayName and clientID (which doesn't sound so secure to use), any suggestions?

My suggestion was actually that we add a new ID field for this purpose, as we have in Upstream. When we did the move to structured configuration we added that new field to be able to have a unique ID for each Upstream.

What I am worried about here is that the logic of extracting the session might be bound to provider logic (like now if we must use session chains) and then we will be stuck in a loop (need providerID to extract session->session holds the providerID->..).

Extracting a previously stored session should be a case of unmarshalling it into the struct. Once we extract it into the struct, we can then pass it to the validation based on the stored value of the providerID in the extracted session right? I think we need to separate the extraction from the validation that currently is tied together

[github-actions]

This issue has been inactive for 60 days. If the issue is still relevant please comment to re-activate the issue. If no action is taken within 7 days, the issue will be marked closed.

[unfor19]

Thank you for this amazing tool.
Any plans on scheduling this feature to the next release?

[NickMeves]

Thank you for this amazing tool.
Any plans on scheduling this feature to the next release?

Yup! We are looking to merge #947 soon and have it available in v7.2.

I can't recall if that PR had the full functionality, or set the stage for structured configs which will be fully released in v8 (available now using alpha config flags)

[smerschjohann]

As far as I can see, the commit of #947 does not enable multiple providers by itself, instead it only enables the configuration of such setups. Are there any other issues where the next steps are handled or is this issue closed mistakenly?

[JoelSpeed]

Yep this was closed by mistake, we have the first part implemented now (the configuration changes), next up will be the actually implementation that allows multiple providers IIUC

[edijsdrezovs]

Looking forward to try it out

[macakmujo]

will this have cli support as well or only config files ?

[JoelSpeed]

Due to the complexity of the structure, this will be config file only

[empperi]

I literally would need this right now. My other option is to change my setup in such a way that I'm running two concurrent instances of oauth2-proxy. Since I'm using the helm chart this isn't a trivial task and it's something I would prefer to avoid if at all possible. I could possibly postpone this a bit if I could be confident that the release providing this functionality would be coming real soon (within a week or two).

So, any guesses when v7.2 would be out with this functionality?

[NickMeves]

I literally would need this right now. My other option is to change my setup in such a way that I'm running two concurrent instances of oauth2-proxy. Since I'm using the helm chart this isn't a trivial task and it's something I would prefer to avoid if at all possible. I could possibly postpone this a bit if I could be confident that the release providing this functionality would be coming real soon (within a week or two).

So, any guesses when v7.2 would be out with this functionality?

It looks like this refactor got picked up and included in v7.1.2 already: https://github.com/oauth2-proxy/oauth2-proxy/blob/master/CHANGELOG.md

I haven't dug in deeply, does it have the alpha-config hooks you need to try this out? Or were those not in the initial refactor PR?

[empperi]

I literally would need this right now. My other option is to change my setup in such a way that I'm running two concurrent instances of oauth2-proxy. Since I'm using the helm chart this isn't a trivial task and it's something I would prefer to avoid if at all possible. I could possibly postpone this a bit if I could be confident that the release providing this functionality would be coming real soon (within a week or two).
So, any guesses when v7.2 would be out with this functionality?

It looks like this refactor got picked up and included in v7.1.2 already: https://github.com/oauth2-proxy/oauth2-proxy/blob/master/CHANGELOG.md

I haven't dug in deeply, does it have the alpha-config hooks you need to try this out? Or were those not in the initial refactor PR?

I ended up going around this issue via a hack(ish) solution but I will look into this a bit later when I have time. It would definitely be much better solution. Cheers for the link!

[hegerdes]

Not stale

[rsrchboy]

Just to sanity check here, the current status of this is that we can configure multiple provider instances (e.g. multiple OIDC IdP's) with the alpha configuration options, but multiple provider instances is not yet supported, right?

[JoelSpeed]

Just to sanity check here, the current status of this is that we can configure multiple provider instances (e.g. multiple OIDC IdP's) with the alpha configuration options, but multiple provider instances is not yet supported, right?

Yes, that's correct

[christopheblin]

we can configure multiple provider instances (e.g. multiple OIDC IdP's)

Is there a documentation somewhere about this ?

I'm not finding anything in the doc (especially in https://oauth2-proxy.github.io/oauth2-proxy/docs/configuration/oauth_provider)

[ianroberts]

It’s implied on the “alpha config” page by the fact that the “providers” option is an array, but as stated above currently only one provider is actually supported in the rest of the code outside of the alpha options YAML model.

Multiple providers will never be supported in the legacy config style, if/when the structured config style graduates beyond being considered “alpha” I’m sure the options will be more fully documented at that point.

[tmloberon]

And when will multiple provider instances be supported? If we can already configure it now.

[tuunit]

Unfortunately, no timeline does exist for when this is going to be supported. As of now you will just have to deploy multiple oauth2-proxy instances.

[github-actions]

This issue has been inactive for 60 days. If the issue is still relevant please comment to re-activate the issue. If no action is taken within 7 days, the issue will be marked closed.

[hegerdes]

Still relevant - not stale

Link: #2279

[bartlomiejduda]

Unfortunately, no timeline does exist for when this is going to be supported. As of now you will just have to deploy multiple oauth2-proxy instances.

Hi. If I understand correctly, this would work as an workaround in this case? Multiple instances should be able to handle multiple providers? Can you provide an example of how it should be configured for single application?

[bartlomiejduda]

It works, but it requires to set up completely new instance of client-side aplication on k8s along with new oauth2-proxy container...
It's at least few days work and it has some serious consequences in the architecture...

I believe that setting up multiple providers on single insance of oauth2-proxy would be much cleaner solution.

[jonathandavis805]

This would be a huge deal - I'm trying to find a way to allow users for front-end web apps to have access to the same api as a native application or a server running in a cloud environment. It doesn't seem possible without extensive additional infrastructure.

[anthraxn8b]

Maybe this can help some of you?
https://adityaoo7.hashnode.dev/authentication-authorization-in-kubernetes-oauth2-proxy-with-dex-idp

[sudmis]

Hi, When will this feature be available to try out?Despite configuring two OIDC providers in the alpha configuration of oauth2-proxy, it seems that only the first provider is being recognized ? Is there a way to get this working? Any guidance or suggestions would be greatly appreciated.

Currently my architecture is Keycloak configured as provider in oauth2-proxy , and Azure is added as Identity provider in Keycloak.
My goal is to streamline the authentication process by allowing direct access to either Azure AD or Keycloak from oauth2-proxy, eliminating the additional hop to Keycloak.

Below is my configmap

providers:
- clientID: 9715c992-ecd0-4103-a406-XXXXXXXXXX
  clientSecret: "XXXXXXXXXXXXXXXX"
  id: oidc=9715c992-ecd0-4103-a406-XXXXXXXXXX
  loginURLParameters:
  - default:
    - force
    name: approval_prompt
  oidcConfig:
    audienceClaims:
    - aud
    emailClaim: email
    groupsClaim: groups
    insecureSkipNonce: true
    issuerURL: https://login.microsoftonline.com/r46d52fb-365c-462b-97d0-XXXXXXXXXX/v2.0
    userIDClaim: email
  provider: oidc
  name: AzureAD
  scope: openid email profile
- clientID: testclient
  clientSecret: "XXXXXXXXXXXXXXXX"
  id: oidc=testclient
  loginURLParameters:
  - default:
    - force
    name: approval_prompt
  oidcConfig:
    audienceClaims:
    - aud
    emailClaim: email
    groupsClaim: groups
    insecureSkipNonce: true
    issuerURL: https://X.X.X.X/realms/Test
    userIDClaim: email
  provider: oidc
  name: Keycloak
  scope: openid email profile

Additionally, here are some logs from the oauth2-proxy container that might provide more context:

[2024/04/01 13:09:46] [main.go:71] WARNING: You are using alpha configuration. The structure in this configuration file may change without notice. You MUST remove conflicting options from your existing configuration.
[2024/04/01 13:09:46] [provider.go:55] Performing OIDC Discovery...
[2024/04/01 13:09:46] [proxy.go:89] mapping path "/" => upstream "http://127.0.0.1:80/"
[2024/04/01 13:09:46] [oauthproxy.go:161] Skipping JWT tokens from configured OIDC issuer: "https://login.microsoftonline.com/r46d52fb-365c-462b-97d0-XXXXXXXXXX/v2.0"
[2024/04/01 13:09:46] [oauthproxy.go:171] OAuthProxy configured for OpenID Connect Client ID: 9715c992-ecd0-4103-a406-XXXXXXXXXX
[2024/04/01 13:09:46] [oauthproxy.go:177] Cookie settings: name:_oauth2_proxy secure(https):true httponly:true expiry:168h0m0s domains: path:/ samesite: refresh:disabled

[github-actions]

This issue has been inactive for 60 days. If the issue is still relevant please comment to re-activate the issue. If no action is taken within 7 days, the issue will be marked closed.

[kaja-mohideen]

This issue is still relevant.

[github-actions]

This issue has been inactive for 60 days. If the issue is still relevant please comment to re-activate the issue. If no action is taken within 7 days, the issue will be marked closed.

[bartlomiejduda]

Issue is still relevant.

[elkh510]

This issue is still relevant.

[pavlm]

Hello. Sorry for the offtopic, but there is another project oauth2-tier. It supports multiple oauth2 providers.