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