这是一个旧问题，但自 2015 年提出以来，已有一些变化。一个显著的变化是，我们现在使用术语 DiscourseConnect 而不是 Discourse SSO。这是因为术语 SSO 可以指代几种不同的认证机制（SAML、OAuth2、Auth0 等），而 DiscourseConnect 是 Discourse 对 SSO 的实现。
启用 DiscourseConnect 后，Discourse 站点上的所有认证都将发生在你通过 discourse connect url 站点设置所指定的外部站点上。这意味着用户将在你的外部站点注册创建账户，而不是在 Discourse 上注册。当用户通过 DiscourseConnect 登录时，账户详情将传递给 Discourse。当用户首次登录 Discourse 时，其账户详情将根据 SSO 负载中提供的数据进行设置。根据某些 Discourse 站点设置的值，账户详情要么会在每次用户登录 Discourse 时继续同步，要么用户可以在 Discourse 上为自己的账户设置不同的值。相关设置如下：
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
请注意，默认情况下，WP Discourse 插件仅在负载中发送以下字段：
usernameemailnamebioavatar_url
可以通过挂钩到 WP Discourse 的 wpdc_sso_params 过滤器钩子，向负载中添加其他参数。
启用 DiscourseConnect 后可能失去的最大功能是：一旦启用，它将成为该站点唯一的认证方法。这意味着无法在 Discourse 上同时启用 DiscourseConnect 和社交登录。不过，你可以在认证提供商站点上启用社交登录。例如，你可以允许用户通过多种社交登录提供商登录你的网站，然后通过 DiscourseConnect 登录 Discourse。类似的方法也可用于 OAuth2 或 SAML。用户可以使用这些认证方法登录你的网站，然后被重定向到 Discourse 通过 DiscourseConnect 登录。
失去的另一项功能是：启用 DiscourseConnect 后，无法同时启用 Discourse 的 invite only 站点设置。
能够轻松将外部应用程序的用户数据同步到 Discourse 是一个重大优势。Discourse 的群组成员资格可以通过 SSO 负载中传递的 add_groups 和 remove_groups 字段轻松设置。默认情况下，WP Discourse 插件不会传递这两个字段，但可以通过挂钩到 WP Discourse 的 wpdc_sso_params 过滤器钩子将它们添加到负载中。
群组成员资格以及负载中可设置的任何其他字段也可以通过后台请求进行同步。详情请参阅 通过 sync_sso 路由同步 DiscourseConnect 用户数据。关于使用 WP Discourse 插件同步群组的详情，请参阅 使用 WP Discourse SSO 管理 Discourse 群组成员资格。
另一个可能的优势是，如果你已经在外部站点拥有大量用户群，启用 DiscourseConnect 将允许这些用户直接登录 Discourse，而无需创建单独的 Discourse 账户。
通过 DiscourseConnect，账户是根据从 SSO 提供商站点传递给 Discourse 的 external_id 进行关联的。WP Discourse 插件使用用户的 WordPress ID 作为 external_id。
是的，默认情况下，WP Discourse 实现的 DiscourseConnect 会设置所有这些字段。如上所述，这些字段是否会在每次用户登录 Discourse 时继续同步，取决于各种 Discourse 站点设置的值。