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 emailauth overrides usernameauth overrides namediscourse connect overrides biodiscourse connect overrides avatardiscourse connect overrides profile backgrounddiscourse connect overrides locationdiscourse connect overrides websitediscourse connect overrides card backgrounddiscourse connect overrides groups
Note that by default, the WP Discourse plugin only sends the following fields in the payload:
usernameemailnamebioavatar_url
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.
Group memberships, and any other fields that can be set in the payload can also be synced in a background request. For details, see Sync DiscourseConnect user data with the sync_sso route. For details about syncing groups with the WP Discourse plugin, see Managing Discourse group membership with WP Discourse SSO.
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.