Discourse OpenID Connect (OIDC)

[david (David Taylor)]

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

[balazsorban44 (Balázs Orbán)]

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

[Lander_Noterman]

@swt2c

When using this plugin with AWS Cognito, to logout, Cognito requires passing a client_id parameter to the logout URL. As best as I can tell, there is no way to add additional query parameters to the logout URL - is that right? If not, is it possible to add this capability?

Have you found a solution to this?

[swt2c (Scott Talbert)]

Unfortunately, no.

[Lander_Noterman]

@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!

[david (David Taylor)]

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

[hhf.technology]

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.

[chrisblech (Christoph Blechschmitt)]

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)?

[hhf.technology]

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.

[davispuh (Dāvis)]

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.

lib/final_destination/ssrf_detector.rb

[david (David Taylor)]

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.

@davispuh

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

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.