I see this message when I try to activate Discourse_id on my test system (3.6.0.beta2-latest):
enable_discourse_id: You must configure Discourse ID credentials ('discourse_id_client_id' and 'discourse_id_client_secret') before enabling this setting.
I use a local Oauth server for OIDC here (keycloak). Maybe the two methods are interfering with each other??
I donât think it interferes with OIDC, but if your instance is not available on the Internet, ID registration will not work. The Discourse ID identity provider has a verification mechanism in place for the Discourse instances that initiate the registration process.
The test instance is online at forum2.netzwissen.de
I see the same message on 2 instances, neither of which has a different OAuth connection.
I moved this to a separate topic⌠do you see any errors in /logs on your instance? It should output some more details there on what is not working under the hood during the registration process.
I would like to understand it a bit more from the technical side.
On my instances, I use OIDC authentication with an external identity provider (Keycloak 26). Discourse ID looks very similar; it is just a different IDP server hosted by Discourse.org. And the error messages (client ID and secret missing) are also reminiscent of the classic OAuth flow. Does this mean that Discourse ID will be activated as an additional IDP authentication path? Because only then would it be useful for my use case. ???
only this one, but relatively regularly so it has nothing to do with the topic.
Message (2 copies reported)
Sidekiq is consuming too much memory (using: 503.02M) for ârpg-foren-appâ, restarting
Backtrace
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activesupport-8.0.2.1/lib/active_support/broadcast_logger.rb:130:in block in warn' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activesupport-8.0.2.1/lib/active_support/broadcast_logger.rb:231:in block in dispatchâ
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activesupport-8.0.2.1/lib/active_support/broadcast_logger.rb:231:in each' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activesupport-8.0.2.1/lib/active_support/broadcast_logger.rb:231:in dispatchâ
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activesupport-8.0.2.1/lib/active_support/broadcast_logger.rb:130:in warn' /var/www/discourse/lib/demon/sidekiq.rb:59:in block in rss_memory_checkâ
/var/www/discourse/lib/demon/sidekiq.rb:53:in each' /var/www/discourse/lib/demon/sidekiq.rb:53:in rss_memory_checkâ
config/unicorn.conf.rb:132:in `block (2 levels) in reload
â
Yes, correct, Discourse ID is another IDP.
@Tealk the sidekiq error is unrelated. Can you share the commit hash for your instance please?
Sure here: 3.5.1 (c96aeda334)
ok. Then I would need a client ID on your IDP (for the public access workflow) or a Client ID and Client Secret (for the confidential access workflow). Another option: add Discourse ID as an external identity broker to the local IDP. For both variants a bit more info would be required 
âŚ
Yes, each Discourse instance registers (under the hood) and sets up a client id and secret.
Now that I look at your instance, I see http/https errors. For ID to work, the site must be under https. This is probably your issue.
@Tealk make sure your site is also working properly on https.
I wouldnât know what I could improve:
https://rpg-foren.com, https://forum.fedimins.net
Console if i try to activate the function:
XHRPUT
https://rpg-foren.com/admin/site_settings/enable_discourse_connect
[HTTP/2 422 86ms]
PUT
https://rpg-foren.com/admin/site_settings/enable_discourse_connect
Status
422
VersionHTTP/2
Transferred713 B (133 B size)
Referrer Policystrict-origin-when-cross-origin
DNS ResolutionSystem
content-type
application/json; charset=utf-8
date
Mon, 20 Oct 2025 16:47:48 GMT
referrer-policy
strict-origin-when-cross-origin
server
nginx
set-cookie
__profilin=p%3Dt%2Ca%3D2b952b1a24003bab45885b2f0abb5118; path=/; secure; HttpOnly; SameSite=Lax
vary
Accept
x-content-type-options
nosniff
x-discourse-route
admin/site_settings/update
x-discourse-username
Tealk
X-Firefox-Spdy
h2
x-frame-options
SAMEORIGIN
x-permitted-cross-domain-policies
none
x-request-id
88adc2fd-5819-43ba-a25c-c1535e6327b0
x-runtime
0.062926
x-xss-protection
0
Accept
*/*
Accept-Encoding
gzip, deflate, br, zstd
Accept-Language
en-US,en;q=0.5
Connection
keep-alive
Content-Length
29
Content-Type
application/x-www-form-urlencoded; charset=UTF-8
Cookie
_t=XuxyDzVA7lmCVSWxjtAAIW%2FwtC6o755siiDMJCwYXt82sKKXgBhQ3XT%2Bv4qY3Zq9Uhm8tgno959kheQuuslCmZmcqFYo1OeNPpJ9hzAkGBnYzzE1p2JB%2Fu8koGRGk21rMt4KkVE4Kid5aA3MwD8Dxdq3Yz9QYwOwmhsqLuFwzAeZVEIHq5M8Vc0YSCZBcWVDT%2FCfO4tXYar%2FmbTbcwLfM%2BnPuO%2F1C%2BOTMAGcn4sZD1vbO%2BRQn0c97DsQkQ%2B19L3csmzoo73ukkKJaIffKdYeAHFHyTIrhOjZbx0gCmHTxyoOUBEZdWRIBA%3D%3D--%2FGRmW%2FeNXPA2phGJ--x%2B6TQc3f4xd4701z6jk5xg%3D%3D; forced_color_mode=auto; _forum_session=juHIw0FO20X1VyNph%2BOFP4iLJHI9eejVQ6lnEKrnLj48q%2BAXWAo%2FRkjqzMqyaJHc3%2BMPW8asNhmYDYWD7I96tO8qLKUxBXEMl64Wa%2BBYFR5q0lWZL9ojHBnoJ18AQ%2BioiJIluwTfHdTikpLScj%2FLLhstWolVA5FCy7dly%2Fu5GNFIiqsfWDBZASUFClW4BKIS4AIX391GbuMCJT4yeftyGKCq%2FnGWYMSd1dPwVF4UK1YFFkA8vpWBCMSDAYivPvb4IYllod%2B3AirPX3KISYsN6p23qHwW%2Bb3KQ7F7ckuxjUSpivaLZAnw6txMlXlmYuQ6lrr6n6qY25ydFteHL064jh%2Fk%2FxBxtY6HkVyoJcth3h089lcAhagtnVSqQRfH8CAd3Ib1BRgOenJHIiRmLtDlyIk9Ixn3IR8l%2BfOwcW7T1yPAUA%3D%3D--DUchcA0kjxsQ2uDR--U3hXxkDHRaVSKCpqpJt%2FAw%3D%3D; __profilin=p%3Dt%2Ca%3D2b952b1a24003bab45885b2f0abb5118
Discourse-Logged-In
true
Discourse-Present
true
Host
rpg-foren.com
Origin
https://rpg-foren.com
Referer
https://rpg-foren.com/admin/config/login-and-authentication
Sec-Fetch-Dest
empty
Sec-Fetch-Mode
cors
Sec-Fetch-Site
same-origin
TE
trailers
User-Agent
Mozilla/5.0 (X11; Linux x86_64; rv:144.0) Gecko/20100101 Firefox/144.0
X-CSRF-Token
06G-4_PiC_1EPpfr3_C8mWopZKLQrkKfaTVUzSF1fUfi22a5GAoo1CIkHNLF0RdelEI7ehqcj6NY2I8YGe9IfA
X-Requested-With
XMLHttpRequest
Pure Docker deployment, no proxy or anything else on the server.
Does Discourse ID already work on forums that use the stable branch? I thought the was added after the release in August.
Ah, indeed, if you are on the stable channel @Tealk, you will have to wait for the next stable release for Discourse ID to be available for you.
Note also that DiscourseConnect is a separate feature.
Okay, then thatâs confusing on the whatâs-new page. Would it be possible to add from which version a feature is included?
Thatâs a good point. I have now updated the Whatâs New feed to only include this item for instances that arenât on stable (and that have the commit in latest that unlocks Discourse ID). If you refresh your Whatâs New feed, you should no longer see this item in your instance on stable.
Yeah, I donât see the news anymore
I already have the settings in the Settings, should the setting be available before itâs implemented?
The enable_discourse_id site setting should not be present for you. (Make sure you donât confuse it with enable_discourse_connect, thatâs something else.)
Now that I look at your instance, I see http/https errors. For ID to work, the site must be under https. This is probably your issue.
⌠interesting, but I dont understand why. Maybe we have a conceptional gap here: the Discourse containers are located behind a SSL accelerator, only accessible via https. But thats for the standard connection coming from âoutsideâ to âinsideâ. In the OAuth use case the discourse container starts the connection from âinsideâ to the IDP which is âoutsideâ. I dont see any option to configure this connection to the discourse ID and force it to be âhttpsâ.
If I compare this with the classic OIDC settings used for OAuth configuration with my own IDP: there we have a âOpenID Connect discovery documentâ setting
https://....realms/[realm-name]/.well-known/openid-configuration
I think we need something similar for the Discourse ID to avoid problems with missing https connections. PS. My test instance has 3.6.0.beta2-latest, Commits ¡ discourse/discourse ¡ GitHub
