Allowing multiple OIDC sources

Contribute Feature
1

This is great, much better than the oauth2 plugin, which didn’t work. But this one does (with Keycloak).

However multiple oidc sources would be a very welcome feature.

Discourse OpenID Connect (OIDC)
2

That’s an interesting idea. Can you tell us some more about your use case to explain the benefits, and if possible which login sources you would want to use?

3

Answering the question in post #2 above: our use case, and which login sources we need.

We run a public community forum for an EU research initiative, on managed Discourse hosting inside the EU.

We need two OIDC providers enabled at the same time:

  1. EU Login, the European Commission’s identity provider. It is used by Commission staff, policy stakeholders, and participants in EU-funded projects. Standard OIDC, with its discovery document at https://ecas.ec.europa.eu/cas/oauth2/.well-known/openid-configuration.
  2. EGI Check-in, a federated academic identity proxy that fronts institutional accounts and ORCID. It is used across the European research infrastructures. Also standard OIDC.

Neither one covers the other’s users. A policy officer signs in with EU Login and has no institutional research identity. A researcher signs in with a university account or with ORCID via our proxy and has no EU Login. Our community is made up of both groups, so picking a single provider means turning away half the people the forum is for.

Both providers speak ordinary OIDC, and either one works on its own. What stops us is that discourse-openid-connect exposes a single, un-numbered settings namespace: openid_connect_client_id, rather than openid_connect_1_client_id and openid_connect_2_client_id. Only one OIDC provider can be configured per site.

We would like support for more than one. The most natural form would be a per-provider settings namespace, either numbered settings or an admin-managed list, where each provider has its own discovery document, client credentials, scope, and button title.

There is earlier prior art in Multiple openid-connect authentication providers from 2021, where the need was several Keycloak realms. That is the same limitation in a different form.

We can provide more information if needed, or test implementations if that can help.

1 Like
7

One thing you could try is to setup an Authentik service and “federate” with these two providers. This way you could have internal SSO for your team, and proxied SSO for external users. Would be a bit harder, considering the need to host your own SSO, but maybe faster than having the OIDC plugin patched, depending on your capacity.

That said, I see (Corporate Login Provider) settings everywhere in Discourse settings, so it would indeed be nice to be able to add our own. Maybe forking the OIDC plugin and changing the names?

4 Likes
8

Thanks for the tip. The EGI Check-in service is already an IdP proxy allowing use of many IdPs.

The current constraint is that the EU Login policy does not allow the use of proxy. They want direct connection with the service.

1 Like
9

In that case, if the other one can do Oauth2, you can configure it with Discourse OAuth2 Basic, so you can keep OIDC for the EU EIDAS. There used to be a SAML plugin as well, maybe it got deprecated.

2 Likes
10

thanks for the suggestion. Indeed, we are currently exploring the use of Discourse OAuth2 Basic with EGI Check-in.

I wanted to bring this case to the attention of the community as the possibility to support multiple OIDC providers will likely benefit more organisations in the future and make things easier.

The SAML option was not in the radar, it might be a third option to consider. I’ve found the plugin: GitHub - discourse/discourse-saml: Support for SAML in Discourse · GitHub

2 Likes