Discourse OpenID Connect

3 posts were split to a new topic: How to configure the OIDC to set the Username as the email account name or a username like value returned from my auth providers?

I managed to connect GitLab and Microsoft (Azure) with this plugin. btw: for the Azure AD service, make sure to use the “Application Client ID” as client id, not the secret ID or value).

How is it possible to connect Discourse with two OIDC providers, e.g. GitLab and Azure?

EDIT: I managed to get GitLab Login working with OAuth2, so my question is now more “theoretical”.

How exactly do you use the ‘claims’ here?

I am not entirely sure how and what that config option is used for.

I think that you would need to fork the plugin and change its name to be able to configure it twice. Maybe you’d fork it and hard code it for one of those services.

Is this plugin also releveant or connected to Discourse Connect at all?

I noticed that if I use the discourse connect override name or username settings, and also affects this plugin. I looked in the source code of the plugin but could not find anything related to those settings.

There’s no connection to DiscourseConnect. The auth_override_* settings apply to all authentication methods. The code for that is part of Discourse core, so that’s why you won’t see them mentioned in the plug-in’s code.

1 Like

oh gotcha, makes sense. thanks!

Hi @david Thanks for this plugin. I’m getting it configured, and I have a few questions:

  1. Is it possible to change the name of the provider from “OpenID Connect” to a name that is indicative of my authentication provider?
  2. Is it possible to force users to use the OpenID Connect provider and eliminate the ability to create a user with username/password? Our goal is to only allow users that already have an account with our identity provider to use our Discourse instance.
  3. If #2 is true, is it possible to circumvent this screen/modal altogether and immediately redirect to the configured OpenID Connect provider when “Log In” is clicked?

I answered #2 myself. It looks like you can disable “local logins” (i.e. username/password) in the settings:

2 Likes

Yes.
At the openid connect enabled setting, the text says ... Customize user interface text here and the link is /admin/customize/site_texts?q=js.login.oidc

3 Likes

#3 happens automatically when you disable local logins.

1 Like

Hi @david,

Can you please take a look at the issue mentioned in following post? I would like to use OIDC plugin over OAuth basic. But I face the same issue - cannot pass parameters to /authorize request. I put the value in plugin in format of foo=bar.

Hi,
Is someone ever able to configure OIDC with authorize parameters? Or I have to change to OAuth basic plugin? Many thanks!

Hey @Avinash_Dane Were you able to figure this out ?

I haven’t been able to get this to work in LinkedIn. Curious if anyone else has? I get as far as logging into LinkedIn after being redirected there when clicking on the signin with…button and then “allowing” my app to use my email from LinkedIn, then I get “Sorry there was an error authorizing your account. Please try again.”

https:/discourse.mysite.com/auth/failure?message=invalid_credentials&origin=https%3A%2F%2Fdiscourse.mysite.com%2F&strategy=oidc

I’m currently not able to get Azure AD working with a common login endpoint.

I’m using the suggested discovery endpoint:

https://login.microsoftonline.com/{tenant}/v2.0/.well-known/openid-configuration

However, this redirects users to my organizational login page, not to the common Azure AD login page that allows using @hotmail.com and other Microsoft accounts. Note that my provider is configured to allow those accounts, and I’ve been able to use them using the same client using NextAuth, so I think that this does work.

I’m not sure if the solution is to use a different discovery document, or something else? Any help would be appreciated :slight_smile:.

Do you really use {tenant} or some actual tenant ID?

1 Like

LOL. I replace that with my tenant ID :slight_smile:. Otherwise I’m pretty sure it wouldn’t work at all…

Which one? The tenant consumers worked for us, while common didn’t.

I deployed it locally in source code according to the following link:

So should the redirect url be 127.0.0.1:4200/auth/oidc/callback or 127.0.0.1:3000/auth/oidc/callback?
When I write 127.0.0.1:4200/auth/oidc/callback, keycloak will prompt Invalid parameter: redirect_uri. I encounter csrf when I write 127.0.0.1:3000/auth/oidc/callback