Using Couchbase Lite for .NET 1.4.1, we have multiple OIDC providers set up in sync gateway configuration and we now need to target a particular provider with a new app, whilst keeping the default_provider for other apps. It says in the sync gateway documentation that:
string
Provider to use for OIDC requests that don’t specify a provider. If only one provider is specified in the providers map, it is used as the default provider. If multiple providers are defined and default_provider is not specified, requests to /db/_oidc must specify the provider parameter.
but we can’t find any way to set “provider” on the OpenIDAuthenticator. It seems as this is not implemented in the library; is this the case? And how can this be rectified? We’re happy to submit a PR if required…
1 Like
I don’t believe the ability to choose your provider is part of Couchbase Lite. OpenID authentication in general has been very troublesome to implement from a library perspective and has been deprecated in 2.0 so it would probably be easier and more beneficial to use the sync gateway REST API directly and bypass the authenticator (some details about that here)
I don’t agree with your statement; the library works with Sync Gateway and therefore the consumer of the library should not be forced to use only the default_provider. Additionally, I don’t believe this requires much change; just need to be able to add provider onto the URL strings e.g. /_oidc?provider={provider}. Authorization Code Flow, albeit more difficult to implement, is more secure than Implicit Flow and would be a significant change to our app(s). However, I understand you’re now in maintenance mode for 1.4.x and this is not a bug per se. So would you definitely not accept a PR for this in 1.4.x?
I didn’t say it shouldn’t be a part of it, just pointed out that I didn’t think it was. It was a long time ago that it was created and I don’t remember the reasons for its lack of inclusion. It also would be slightly more than what you said as the provider would need to be taken into account during the token storage so that there would be the ability to switch (otherwise after switch the wrong tokens would be used).
Regardless of whether or not we would accept a PR, there are no more planned releases for the 1.x line anyway so even if it is accepted (which would require the other platforms to make the same change as well) it may not ever see an official release.
Attn @priya.rajagopal for consideration