Discourse OpenID Connect (OIDC)

Plugin
, ,
292

Hi @balazsorban44, thanks for the reminder on this. I’ve done a first pass of reviewing the PR. If the author doesn’t have time to work on those things, then it’s likely something we can take on. I agree having PKCE support would be nice.

However, it’s worth noting: I don’t think Discourse is vulnerable to the “authorization code interception” attacks which PKCE protects against. Discourse authentication always happens in-browser over https, and does not use OS-level custom URL schemes which can be intercepted by other apps.

But of course, there is no harm in adding the extra layer of security :+1:

3 Likes
293

Not necessarily concerned about security.

I addressed the feedback here, keeping the original contributor’s history for credit: feat: PKCE support by balazsorban44 · Pull Request #86 · discourse/discourse-openid-connect · GitHub

Happy to finish the swing on it :slight_smile:

1 Like
294

Have you found a solution to this?

295

Unfortunately, no.

296

@swt2c I hacked it into the plugin by adding

  params << ["client_id", "<my-client-id>"]
  params << ["logout_uri", post_logout_redirect] if post_logout_redirect

after the params << ["post_logout_redirect_uri", post_logout_redirect] if post_logout_redirect line in plugin.rb.

Would be great to get official support for this!

298

@balazsorban44 thanks for taking this on! I just merged the PR, so we now have opt-in PKCE support in the plugin :tada:

3 Likes
299

hey Chris,
how did you integrate Authentik with this plugin. any insights will be helpful. we are struggling since couple of weeks to work it correct.

300

Hmm, I can’t remember something special. What is your problem exactly? Do you want to share some screenshots of your configuration (maybe via PM)?

1 Like
301

thanks for replying chris. sure. will connect with you later in the week when my dev team is around who was working on authentik. main issues are with the flow and outpost.

1 Like
304

I have interesting issue, before deploying publicly I want to test that everything works so my OIDC provider is hosted locally (private subnet) and not accessible from internet.
Unfortunately this fails because Discourse doesn’t allow connecting to private IPs.
oidc.example.org resolves to private IP.

OIDC Log: Fetching discovery document from https://oidc.example.org/application/o/discourse/.well-known/openid-configuration
OIDC Log: Fetching discovery document raised error Faraday::ConnectionFailed FinalDestination: all resolved IPs were disallowed
OIDC Log: Discovery document is

---

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

I think because openid_connect_discovery_document can only be changed by Admin it should be trusted and allow even private IPs.

305

There’s a site setting called ‘allowed_internal_hosts’. If you add the internal hostname to that list, then requests to it will be allowed through the SSRF Detector.

In shared hosting services (like the official discourse.org hosting), admins are not trusted to make requests within the hosting environment, so that’s why this protection exists by default.

306

Apologies but I am not certain I can follow the instructin to install the plugin. I am runnin discourse in my local docker environemnt, and I can’t really find an app.yml to add the configuration.
Might be a stupid question, but is there a guido to install in a local dev environemnt?

307

For a Docker dev environment, try checking under /var/discourse/containers/app.yml?
However, for non-Docker dev installs, see here:

308

The problem is that I can’t find a folder containers

310

Assuming that you followed this guide, perhaps follow this post to install plugins?

312

Hi there.
I added this plugin and it works fine. The problem I see is, our discourse app has aliases, so I can login with 2 urls. Both have been configured in Azure with proper callback urls. I noticed that, the call to https://discourse.company.com/auth/oidc is returning the Location URL with the alias URL, like https://login-blah-bla/authorize?client_id=&redirect_uri=https%3A%2F%[2Fdiscourse.us.company.com](http://2fdiscourse.us.company.com/)%2Fauth%2Foidc%2Fcallback.
Shouldn’t it respect the originated url?

There is an openid_connect_error_redirects but that I believe is for in case of errors. Any idea how I can change the redirect to the authority(aka discourse.company.com).

313

During a manual bundle install I get this:

Post-install message from oauth2:

You have installed oauth2 version 1.4.11, which is EOL.
No further support is anticipated for the 1.4.x series.

and recommendations to upgrade to oauth2 version 2. Would feel a lot more comfortable without such messages, any plans to upgrade?

I also get:

You have installed oauth version 1.1.0, congratulations!

Non-commercial support for the 1.x series will end by April, 2025. Please make a plan to upgrade to the next version prior to that date.
The only breaking change will be dropped support for Ruby 2.7 and any other versions which will also have reached EOL by then.

but I guess that’s not “you”?