### Author:  [@david](https://meta.discourse.org/u/david)
#### Post date: [October 3, 2024, 12:30pm UTC](https://meta.discourse.org/t/discourse-openid-connect-oidc/103632/292 "2024-10-03T12:30:21Z")
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 👍
---
### Author:  [@balazsorban44](https://meta.discourse.org/u/balazsorban44)
#### Post date: [October 4, 2024, 3:39pm UTC](https://meta.discourse.org/t/discourse-openid-connect-oidc/103632/293 "2024-10-04T15:39:20Z")
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](https://github.com/discourse/discourse-openid-connect/pull/86)
Happy to finish the swing on it 🙂
---
### Author:  [@Lander\_Noterman](https://meta.discourse.org/u/Lander_Noterman)
#### Post date: [October 14, 2024, 1:09pm UTC](https://meta.discourse.org/t/discourse-openid-connect-oidc/103632/294 "2024-10-14T13:09:04Z")
> [@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?
---
### Author:  [@swt2c](https://meta.discourse.org/u/swt2c)
#### Post date: [October 14, 2024, 1:26pm UTC](https://meta.discourse.org/t/discourse-openid-connect-oidc/103632/295 "2024-10-14T13:26:16Z")
Unfortunately, no.
---
### Author:  [@Lander\_Noterman](https://meta.discourse.org/u/Lander_Noterman)
#### Post date: [October 14, 2024, 2:07pm UTC](https://meta.discourse.org/t/discourse-openid-connect-oidc/103632/296 "2024-10-14T14:07:04Z")
@swt2c I hacked it into the plugin by adding
```plaintext
params << ["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!
---
### Author:  [@david](https://meta.discourse.org/u/david)
#### Post date: [October 16, 2024, 11:32am UTC](https://meta.discourse.org/t/discourse-openid-connect-oidc/103632/298 "2024-10-16T11:32:47Z")
@balazsorban44 thanks for taking this on! I just merged the PR, so we now have opt-in PKCE support in the plugin 🎉
---
### Author:  [@hhf.technology](https://meta.discourse.org/u/hhf.technology)
#### Post date: [October 21, 2024, 9:48am UTC](https://meta.discourse.org/t/discourse-openid-connect-oidc/103632/299 "2024-10-21T09:48:22Z")
hey Chris,
how did you integrate [Authentik](https://goauthentik.io/) with this plugin. any insights will be helpful. we are struggling since couple of weeks to work it correct.
---
### Author:  [@chrisblech](https://meta.discourse.org/u/chrisblech)
#### Post date: [October 21, 2024, 3:27pm UTC](https://meta.discourse.org/t/discourse-openid-connect-oidc/103632/300 "2024-10-21T15:27:45Z")
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)?
---
### Author:  [@hhf.technology](https://meta.discourse.org/u/hhf.technology)
#### Post date: [October 21, 2024, 3:58pm UTC](https://meta.discourse.org/t/discourse-openid-connect-oidc/103632/301 "2024-10-21T15:58:40Z")
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.
---
### Author:  [@davispuh](https://meta.discourse.org/u/davispuh)
#### Post date: [February 9, 2025, 7:29pm UTC](https://meta.discourse.org/t/discourse-openid-connect-oidc/103632/304 "2025-02-09T19:29:22Z")
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.
```plaintext
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.
>
---
### Author:  [@david](https://meta.discourse.org/u/david)
#### Post date: [February 10, 2025, 10:53am UTC](https://meta.discourse.org/t/discourse-openid-connect-oidc/103632/305 "2025-02-10T10:53:36Z")
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](http://discourse.org) hosting), admins are not trusted to make requests within the hosting environment, so that’s why this protection exists by default.
---
### Author:  [@Cesare\_Caoduro](https://meta.discourse.org/u/Cesare_Caoduro)
#### Post date: [February 24, 2025, 5:54am UTC](https://meta.discourse.org/t/discourse-openid-connect-oidc/103632/306 "2025-02-24T05:54:03Z")
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?
---
### Author:  [@NateDhaliwal](https://meta.discourse.org/u/NateDhaliwal)
#### Post date: [February 24, 2025, 7:09am UTC](https://meta.discourse.org/t/discourse-openid-connect-oidc/103632/307 "2025-02-24T07:09:09Z")
For a Docker dev environment, try checking under `/var/discourse/containers/app.yml`?
However, for non-Docker dev installs, see here:
> [@Install plugins in your non-Docker development environment](https://meta.discourse.org/t/install-plugins-in-your-non-docker-development-environment/205337/1):
>
> (This guide only covers non-docker dev install. For Docker dev whale see [Install Discourse for development using Docker](https://meta.discourse.org/t/beginners-guide-to-install-discourse-for-development-using-docker/102009)) If you’ve followed the [instructions to set up your local discourse](https://meta.discourse.org/t/how-do-i-set-up-a-local-discourse-development-environment/182882/1), you can install a plugin locally: Stop your local server if it’s running. Download the plugin repo and save it your /plugins folder. Alternatively, you can [use a symlink](https://meta.discourse.org/t/beginners-guide-to-creating-discourse-plugins-part-4-git-setup/31272#creating-a-symlink-3). If the plugin includes migrations (you’ll see them in db/migrate), run them with: LOAD\_PLUGINS=1 bundle exec rake db:migrate fro…
---
### Author:  [@Cesare\_Caoduro](https://meta.discourse.org/u/Cesare_Caoduro)
#### Post date: [February 24, 2025, 7:22am UTC](https://meta.discourse.org/t/discourse-openid-connect-oidc/103632/308 "2025-02-24T07:22:39Z")
The problem is that I can’t find a folder containers
---
### Author:  [@NateDhaliwal](https://meta.discourse.org/u/NateDhaliwal)
#### Post date: [February 24, 2025, 7:28am UTC](https://meta.discourse.org/t/discourse-openid-connect-oidc/103632/310 "2025-02-24T07:28:16Z")
Assuming that you followed [this guide](https://meta.discourse.org/t/install-discourse-for-development-using-docker/102009), perhaps follow [this post](https://meta.discourse.org/t/install-discourse-for-development-using-docker/102009/113) to install plugins?
---
### Author:  [@zabin](https://meta.discourse.org/u/zabin)
#### Post date: [March 5, 2025, 7:57pm UTC](https://meta.discourse.org/t/discourse-openid-connect-oidc/103632/312 "2025-03-05T19:57:33Z")
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](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](https://login-blah-bla/authorize?client_id=&redirect_uri=https%3A%2F%25%5B2Fdiscourse.us.company.com%5D(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](http://discourse.company.com/)).
---
### Author:  [@steinhh](https://meta.discourse.org/u/steinhh)
#### Post date: [March 13, 2025, 3:55pm UTC](https://meta.discourse.org/t/discourse-openid-connect-oidc/103632/313 "2025-03-13T15:55:43Z")
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”?
---
### Author:  [@SamKer](https://meta.discourse.org/u/SamKer)
#### Post date: [May 28, 2025, 12:26pm UTC](https://meta.discourse.org/t/discourse-openid-connect-oidc/103632/314 "2025-05-28T12:26:58Z")
Hello,
the Allow new registrations option is strictly required for the plugin to function. It allows to automatically create the account at the first connection to discourse and displays a “register” button. But would it be possible to allow its deactivation: that is to say, not to allow the user connecting via openidconnect to modify their parameters and create their account directly. This would allow to remove the “register” buttons from the display that have no reason to be in this context.
Sincerely
---
### Author:  [@marlowleon](https://meta.discourse.org/u/marlowleon)
#### Post date: [June 18, 2025, 11:23pm UTC](https://meta.discourse.org/t/discourse-openid-connect-oidc/103632/315 "2025-06-18T23:23:10Z")
where you able to figure it out? im stuck on the same message.
---
### Author:  [@marlowleon](https://meta.discourse.org/u/marlowleon)
#### Post date: [June 19, 2025, 3:00am UTC](https://meta.discourse.org/t/discourse-openid-connect-oidc/103632/316 "2025-06-19T03:00:11Z")
Hey, were you able to set this up? i dont know why im at a dead stop with this, out of the hundreds of apps ive managed with openid or auth this one is giving me the most trouble
[Previous page](https://meta.discourse.org/t/discourse-openid-connect-oidc/103632.md?page=1)
[Next page](https://meta.discourse.org/t/discourse-openid-connect-oidc/103632.md?page=3)