如何在不暴露密码的情况下将两个不同的网站集成到一个共同的登录名中?

How to integrate two disparate websites with a common login without exposing passwords?

我有一个网站,称之为 "Site One",用户可以在其中使用用户名和密码创建帐户。为了安全起见,我随后对用户密码进行加盐和哈希处理,并将其存储在 SQL 数据库中。一切都很好。

现在输入"Site Two",这是另一家公司写的。我们想集成这两个应用程序,这样如果用户登录到站点二,他们将能够:

  1. 通过网络在站点一上创建帐户 API。
  2. 一键式从站点二无缝登录回到站点一。

如果站点二无法存储和检索他们创建的用户帐户的密码,这是否可以实现?我能想到的唯一方法是,在站点二通过 WebAPI 调用站点一以创建帐户后,站点二必须能够存储用于创建该帐户的密码首先,这就打开了一个很大的安全漏洞,以防有人能够获得密码。

我想作为一个额外的安全层,我可以防止使用该密码,除非登录信息是从已知 IP 地址发布的,但我不确定这是否足够保护。

考虑使用 SAML 2.0 实施单个 sign-on (SSO),其中站点一是身份提供商 (IdP) 和服务提供商 (SP),站点二是服务提供商。

假设用户将首先访问站点二,那么您可能希望在站点二上实施服务提供商发起的 SSO。这样做的效果是,每当用户请求站点二上的安全资源时,用户将被定向到站点一,这将提示他们输入用户名和密码。一旦通过身份验证,用户将 re-directed 返回站点二以访问用户最初请求的受保护资源。

概述取自OASIS SAML 2.0 documentation

  1. The user attempts to access a resource on sp.example.com. The user does not have a valid logon session (i.e. security context) on this site. The SP saves the requested resource URL in local state information that can be saved across the web SSO exchange.

  2. The SP sends an HTTP redirect response to the browser (HTTP status 302 or 303). The Location HTTP header contains the destination URI of the Sign-On Service at the identity provider.

  3. The Single Sign-On Service determines whether the user has an existing logon security context at the identity provider that meets the default or requested authentication policy requirements. If not, the IdP interacts with the browser to challenge the user to provide valid credentials.

  4. The user provides valid credentials and a local logon security context is created for the user at the IdP.

  5. The IdP Single Sign-On Service builds a SAML assertion representing the user's logon security context. The Single Sign-On Service sends the HTML form back to the browser in the HTTP response.

  6. The browser, due either to a user action or execution of an “auto-submit” script, issues an HTTP POST request to send the form to the SP's Assertion Consumer Service.

  7. An access check is made to establish whether the user has the correct authorization to access the resource. If the access check passes, the resource is then returned to the browser.