I’m considering the WP-Discourse plugin to integrate my WP site with Discourse, but would be interested in understanding a bit better what the benefits and costs are. What do you lose exactly when you turn on SSO in terms of discourse functionality, and what do you gain? How are the WP and Discourse accounts linked? For example, can the user profile info like picture, username, email address, “about me” and location be shared across both platforms?
Thanks for any guidance. I’d love to be directed also any good examples of the wp-discourse plugin in action, with and without SSO.
This is an old question, but there have been a few changes since it was asked in 2015. One notable change is that we are now using the term DiscourseConnect instead of Discourse SSO. This is because the term SSO can be used to refer to a few different authentication mechanisms (SAML, OAuth2, Auth0…) DiscourseConnect is Discourse’s implementation of SSO.
When DiscourseConnect is enabled, all authentication on the Discourse site will occur on the site that you set with the discourse connect url site setting. This means that users will create their accounts by registering on your external site instead of registering on Discourse. Account details will be passed to Discourse when users login via DiscourseConnect. When users first login to Discourse, their account details will be set from the data that’s provided in the SSO payload. Depending on the values of some Discourse site settings, account details will either continue to be synced every time the user logs into Discourse, or users will be able to set distinct values for their account on Discourse. The relevant setting for this are:
auth overrides email
auth overrides username
auth overrides name
discourse connect overrides bio
discourse connect overrides avatar
discourse connect overrides profile background
discourse connect overrides location
discourse connect overrides website
discourse connect overrides card background
discourse connect overrides groups
Note that by default, the WP Discourse plugin only sends the following fields in the payload:
Additional parameters can be added to the payload by hooking into the WP Discourse wpdc_sso_params filter hook.
Possibly the biggest functionality that is lost by enabling DiscourseConnect is that when enabled, it becomes the only authentication method for the site. This means social logins cannot be enabled on Discourse along side DiscourseConnect. You can enable social logins on your auth provider site though. For example, you could allow users to login to your website through various social login providers and then have them login to Discourse via DiscourseConnect. A similar approach can be used with OAuth2 or SAML. Users can login to your website with those auth methods, then be redirect to Discourse to login via DiscourseConnect.
Another functionality that is lost is that the Discourse invite only site setting cannot be enabled along side DiscourseConnect.
The ability to easily sync user data from an external application to Discourse is a big benefit. Discourse group memberships can easily be set with the add_groups and remove_groups fields that are passed in the SSO payload. The WP Discourse plugin does not pass either of these fields by default, but they can be added to the payload by hooking into the WP Discourse wpdc_sso_params filter hook.
Another possible gain is that if you already have a large user base on an external site, enabling DiscourseConnect will allow these users to login to Discourse without having to create a separate Discourse account.
With DiscourseConnect, accounts are linked based on the external_id that is passed from the SSO provider site to Discourse. The WP Discourse plugin uses the user’s WordPress ID for the external_id.
Yes, by default all of those fields are set with the WP Discourse implementation of DiscourseConnect. As noted above, whether or not they will continue to be synced each time a user logs into Discourse depends on the value of various Discourse site settings.