与不同提供商的集中身份管理

Centralized identity management with different providers

我将构建一个 Web 应用程序,允许用户使用他们的 Google 或 Twitter 帐户登录。我认为 OpenID Connect(OAuth2) 是当今验证身份的标准。 我还想提供几个 API 服务,这些服务只能通过 Google 或 Twitter 的有效访问令牌访问。

例如,上面的所有四个 API 都将是 public,因此我必须防止未经授权的用户访问。对于基于 NodeJS 的 API 服务,我可以使用 http://www.passportjs.org/ 来保护所有 API。

假设,将来 API 的数量将增长到例如 20 API,并且也将允许使用 Facebook 帐户登录。 同样,所有 API 都必须受到保护,我必须用 http://www.passportjs.org/ 进行 16 次保护。 除了添加新的提供商 Facebook,我还必须对所有 20 APIs 进行更改。

问题是,他们是一种保持集中的方式,这意味着将来我将提供更多提供商,例如 GITHUB 用于登录我想在一个地方而不是在20个地方。 这个工具 https://www.ory.sh/hydra 是我需要的吗?

这些可能是 OAuth 2.0 和 Open ID Connect 的两个主要功能:

  • 通过多个身份提供商联合登录您的用户界面,并能够以集中方式轻松添加新选项,例如 GitHub

  • 完全控制访问令牌中包含的声明,以便您的 API 可以根据需要授权请求

外国访问令牌

您应该尽量避免在您的应用中使用这些。您的 UI 和 API 应该只使用您自己的授权服务器 (Ory Hydra) 颁发的令牌,该服务器管理与身份提供者的连接。添加新的登录方法将只涉及集中配置更改,UI 或 API 中的代码更改为零。

如果您还没有授权服务器

也许可以看看 Curity Identity Server 及其 free community edition - use sign in with GitHub,它对这两个领域都有强大的支持:

外部资源

上述情况的一个例外是,您的 API 有时可能需要在登录后通过调用 Google API 访问用户的 Google 资源。这需要 Google 颁发的令牌。它可以通过 embedded token approach 进行管理 - 虽然听起来您现在不需要它。