Official Single-Sign-On for Discourse (sso)


(Pierre-Olivier Latour) #323

When returning the SSO payload to Discourse, what exactly happens with avatar_url?

  • Does Discourse truly download it every time or only if the URL is different?
  • What happens if avatar_url is missing or empty on a subsequent authentication? Is the Discourse avatar cleared or left untouched?
  • Is there a recommended size to return the avatar image at, or at least a maximum one (in pixels or bytes)?

(Simon Cossar) #324

It looks like that all happens here:

So if there is no avatar_url in the request, nothing will happen. If there is an avatar_url and either force_update is set to true, or the user’s saved external_avatar_url doesn’t equal the avatar_url from the request then the avatar image is imported.

(Pierre-Olivier Latour) #325

So if editing avatar is disabled with the SSO setting, and a user clears their avatar on the external server, it will not be cleared in Discourse. Wouldn’t that be a bug? I would expect that not having avatar_url in the payload would leave the Discourse avatar unchanged, but if it’s set, even to an empty string, it should always override it.


That’s my problem. If an User change his avatar on the main site, it wouldn’t change on the discourse side until the user log off and log in from Discourse. Same for others attributes (name or custom attributes).

(Sam Saffron) #327

This is why we have the sync sso endpoint


Thanks @sam

Synchronizing SSO records

You can use the POST admin endpoint /admin/users/sync_sso to synchronize an SSO record, pass it the same record you would pass to the SSO endpoint, nonce does not matter.

Any details about this feature or how to use it ?

(Andi Ruggles) #329

Did you ever find a solution to this? We’re going through the same experience right now.

(Simon Cossar) #330

Are you using the wp-discourse plugin? If so, you can set the ‘Path to your login page’ option to /my-account on the plugin’s settings page. On your Discourse settings it’s fine to leave the ‘sso url’ setting as It gets redirected to the correct page by WordPress.

FYI If you are enabling registration through WooCommerce on the ‘Checkout’ or ‘My Account’ page, users who register that way will be forced to verify their email address by Discourse before they can use the forum.


Unfortunately not solved this yet completely. However I believe they have
pushed some updates which makes it easier?

Have you tried it out yet?



I got the request argument:


sso seems too long, is that something wrong?

(Felix Freiberger) #333

Looks good! Here’s an example URL from my installation, which has a working SSO setup:



Thank you @fefrei, I love you so much

You help me a lot!

I just forgot to decode url escape character, so always get the wrong sid :stuck_out_tongue:

(Jeff Willette) #335

The logout redirect setting seems to rely on GET request logouts, my main site requires a post request and I cannot figure out how to make that happen…

I have tried making some custom javascript in the customization section, but the login link is inserted after the document loads so it is hard to get at with jquery. Any thoughts on this?

(Kane York) #336

Bring the user to a page with a large button with text along the lines of “Click to finalize logout.” Click, post, done. With CSRF.

(Jeff Willette) #337

I could do this, but it leaves my logout procedure somewhat fragmented. What if someone logs off discourse and then never follows the last step? they will then be logged into one and not the other. It is also ugly because the alert pops up briefly which says the user is logged out of discourse and then it redirects right away, it is very jarring

(Sam Saffron) #338

Then make a get based page that logs out?

(Jeff Willette) #339

@sam I could, but I have two issues with that…

  1. It still leaves the jerky alert > redirect when one clicks logout
  2. what if someone posts an image <img src="">. An edge case for sure, but it still leaves the best solution as sending a post request from javascript and staying on the discourse subdomain

(Kane York) #340

This is vulnerable to CSRF form submission - <form action=> .submit() - but I suppose that’s still better than logout on GET. As long as you know the risk is there.

I think it wouldn’t be too hard to make the after-logout page submit a form that looks exactly like that?

Oh, idea - you can see if the browser sends an Origin header with the post and filter on that.

(Jeff Willette) #341

If I make my other sites csrf cookie available on my subdomain then how is the javascript logout vulnerable to anything that isn’t already possible on my main site? Why couldn’t the same vulnerability be exploited in the main site on a post request?

Is the after logout page you speak of the alert that comes up and says you have been logged out?

(Jeff Willette) #342

I think something needs to be added to the main post for clarity…

Where it says this:

Synchronizing SSO records

You can use the POST admin endpoint /admin/users/sync_sso to synchronize an SSO record, pass it the same record you would pass to the SSO endpoint, nonce does not matter.

I think it should also include:

If you call admin/users/sync_sso from another site, you will need to include a valid admin api_key and a valid api_username as url parameters