Discourse OpenID Connect

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?

Is there any way this plugin could overrides avatar, just like DiscourseConnect does?

1 Like

Hi! Our OpenID provider has had a glitch where they accidentally gave out too much information about users (the Norwegian equivalent of a social security number) and they’re now asking whether our Discourse instance may have stored the information. The information in question would most likely appear as something like this in the userinfo response:

“norEduPersonNIN”: “23080374554”

Is there any chance this extraneous information could have been stored anywhere?

It seems unlikely to me, but

  • Does the entire response get logged/stashed away somewhere?
  • Does the presence of such a tag trigger an error message that is stored/logged somewhere?
  • Does the system extract & store all it can from the response, “just in case”?

Would really appreciate a definitive response along the lines of “no chance” or “yeah, it gets stored but here’s how you delete that information” :slight_smile:

Cheers,
Stein

Hi @steinhh, I think this is the best description:

The information is stored in the user_associated_accounts database table, so you could take a look there to see what might need to be cleaned up.

1 Like

Thanks! Nothing suspicious turns up there. I also got our “database hotel” guys to do a full dump of the database, and grepping among the contents turned up zilch. Phew. This was a newspaper-worthy incident, although AFAIK the SSN-equivalents have not yet been leaked per se, just erroneously given out to auth clients.

1 Like