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.
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.”
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 .
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
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):
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.
@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.
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.