Discourse OpenID Connect

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

What is running on ports 4200 and 3000? The port of the redirect_uri setting in keycloak should be the one of discourse.

The discourse server runs on port 3000, and the discourse embercli runs on port 4200.

Then the redirect_uri should be 127.0.0.1:4200/auth/oidc/callback

But this will encounter csrf

The code causing the issue is here

I debugged the source code of this plugin and found some clues. Then I checked the discourse log

It seems that the sessionid has changed, causing session[“omniauth.state”] to be lost. So why sessionid changes?

Does anyone know if it’s possible to map the name claim rather than the preferred_username claim to the username (nickname) displayed during signup and shown in the ‘Create Account’ pop-up?

Here is the information we receive from Keycloak:

{
 ..
  "scope": "openid email",
  "sid": "f0f20a2a-19e5-4581-8a45-c1250376f226",
  "email_verified": true,
  "name": "Ted Bush",
  "preferred_username": "tb",
  "given_name": "Ted",
  "family_name": "Bush",
  "email": "ted.bush@example.com"
...
}

By default, the preferred_username (in this example, “tb”) is used as the username (nickname).

However, we would like to configure the integration in such a way that the name (“Ted Bush”) is used as the username (nickname) instead.

Thanks.

I see the “Use a user’s full name when suggesting usernames.” setting in the Users setting section. But it seems to have no effect for OpenID Connect?

Or does this work for anybody?

Yes, it works for me when testing it with the Google OAuth2 server as the OpenID Connect provider.

I think the issue you are running into is related to how the Discourse username suggester code works. Keycloak is returning a preferred_username. If a preferred_username is set in the userinfo that’s returned from the identity provider, it takes precedence over the value of either the name or given_name/family_name fields.

For reference, the problem is happening here (preferred_username is set as the value of username in a method that gets called before this):

Then here:

Since the value of preferred_username is the first argument that gets passed to the username suggester code, it will get used. That means that the use_name_for_username_suggestions setting isn’t having any effect for this case. I think it was intended to catch the case of no preferred_username being passed back from the identity provider.

I’m not seeing a good workaround for this, unless you can prevent the preferred_username from being passed to Discourse from Keycloak.

1 Like

@simon, you are correct; I have verified what you mentioned using a test Keycloak instance. When I configure Keycloak to omit preferred_username from being passed to Discourse, the first and last names are indeed used by the Discourse username suggester.

However, we cannot configure our production Keycloak in this manner, as the client configuration is shared with several other clients, not just Discourse.

It would be beneficial to have a way to influence this behaviour within the plugin.

1 Like

I’m still having trouble with this. I’m getting the following error:

(oidc) Authentication failure! invalid_credentials: OAuth2::Error, invalid_request: A required parameter "client_secret" is missing {"error":"invalid_request","error_description":"A required parameter

I’t san omniauth error and appears to be related [potentially] to this: No longer works with oauth2 gem v2.0+ · Issue #68 · decioferreira/omniauth-linkedin-oauth2 · GitHub

Help is appreciated!

Hello there!

I’m using this plugin to sync user from a django site, but the avatar is sync only on creation. If user change it in django, it is not sync in discourse.

In fact, in Discourse managed_authenticator.rb, the retrieve_avatar return early if the user already have a custom avatar setup:

  def retrieve_avatar(user, url)
    return unless user && url
    return if user.user_avatar.try(:custom_upload_id).present?
    Jobs.enqueue(:download_avatar_from_url, url: url, user_id: user.id, override_gravatar: false)
  end

Did I missed something or discourse-openid-connect can not update avatar on login?

I also have question for the “website”, “location” and “bio_raw”. DiscourseConnect sync it on login, can openidconnect also do it? All are supported in the oidc claims

cheers!

I’m receiving the following errors:


(oidc) Authentication failure! openid_connect_discovery_error: OmniAuth::OpenIDConnect::DiscoveryError, Discovery document is missing

OIDC Log: Fetching discovery document raised error Faraday::ConnectionFailed FinalDestination: lookup failed

I have my plugin setting “openid connect discovery document” set in the Admin Settings as: https://<auth_provider>/.well-known/openid-configuration and I can successfully hit it in the App Docker container that is running with a Curl command and even in the Rails console.

Any idea why I’m receiving these errors? Can’t integrate properly because of this. Also, I’m behind the intranet and using a company proxy if that is any help. Like i said, with the proxy eneabled in the ENV of the container, i can properly hit the “openid connect discovery document” url.

Same here, with v3.1.3…

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.

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?