I found the problem: the header was not set to “Content-Type: application/json”. And I can see it was the same for @qlands above.
The only remaining issue for me now is the same as @nodomain : the account is created successfully but the avatar is not included. Sample response:
Body: {
"access_token":"...",
"token_type":"bearer",
"expires_in":"3600",
"scope":"profile",
"profile" : {
"id":1234,
"email": "...",
"name": "...",
"picture": "https://somedomain.com/somevalidpicture.jpg"
}
}
And it is correctly parsed, since it appears in the following log:
OAuth2 Debugging: after_authenticate response:
creds: {"token"=>"...", "expires_at"=>1702053692, "expires"=>true}
uid: 1234
info: {"email"=>"...", "name"=>"...", "avatar"=>"https://somedomain.com/somevalidpicture.jpg"}
extra: {}
I checked that the picture address is correct, and it’s size is 300x300.
Any idea for that one?
Edit: someone just created an account, and it took the picture from Gravatar. Maybe the valid picture in the json gets overriden by a blank result from Gravatar?
Authentik as OAuth provider
I’m currently playing with Authentik and would like to ask if anyone else has any experience with it and discourse?
Unfortunately I haven’t found an official support document for discourse.
There are a lot of settings to mess around with 
Portainer has a much simpler implementation of OAuth.
Portainer, just for comparison:
1 Like
How’s it going? I want to implement SSO w/Authentik on Discourse and Ghost, but my project it’s on standby at the moment.
Any advice should be greatly appreciated 
1 Like
Has anyone encountered the issue where SSO is located on an internal network, and when Discourse tries to access the SSO site using an internal IP address, it becomes inaccessible?
tail -f production.log
(oauth2_basic) Setup endpoint detected, running now.
(oauth2_basic) Request phase initiated.
Started POST "/presence/update" for 10.10.10.10 at 2024-06-15 18:19:44 +0000
Processing by PresenceController#update as */*
Parameters: {"client_id"=>"xxx", "present_channels"=>["/chat-user/core/1"]}
Completed 200 OK in 26ms (Views: 0.2ms | ActiveRecord: 0.0ms | Allocations: 1895)
Started GET "/auth/oauth2_basic/callback?code=xxxx&state=xxxx" for 10.10.10.10 at 2024-06-15 18:19:49 +0000
(oauth2_basic) Setup endpoint detected, running now.
(oauth2_basic) Callback phase initiated.
OAuth2::ConnectionError (FinalDestination: all resolved IPs were disallowed)
lib/final_destination/ssrf_detector.rb:105:in `lookup_and_filter_ips'
lib/final_destination/http.rb:15:in `connect'
lib/middleware/omniauth_bypass_middleware.rb:43:in `call'
lib/content_security_policy/middleware.rb:12:in `call'
lib/middleware/anonymous_cache.rb:391:in `call'
lib/middleware/csp_script_nonce_injector.rb:12:in `call'
config/initializers/008-rack-cors.rb:14:in `call'
config/initializers/100-quiet_logger.rb:20:in `call'
config/initializers/100-silence_logger.rb:29:in `call'
lib/middleware/enforce_hostname.rb:24:in `call'
lib/middleware/request_tracker.rb:289:in `call'
Webpage Error
Oops
The software powering this discussion forum encountered an unexpected problem. We apologize for the inconvenience.
Detailed information about the error was logged, and an automatic notification generated. We'll take a look at it.
No further action is necessary. However, if the error condition persists, you can provide additional detail, including steps to reproduce the error, by posting a discussion topic in the site's feedback category.
I checked my firewall logs, but didn’t find any blocking records! Moreover, both discourse and SSO are located on the internal network, so there shouldn’t be any firewall blocking or request interception issues!
But when I point the IP address of the SSO site to the external public network, it works normally again!
Is this a bug in the plug-in or a configuration problem on my side?
You can add the hostname of your internal SSO site to the ‘allowed_internal_hosts’ site setting. Then Discourse will be able to connect to it.