OpenID Connect、oAuth2 - 从哪里开始？

Question

我不确定在实施过程中应该采用哪种方法，需要一些指导。

我有一个内置于 Yii2 框架 (PHP) 的 REST API (api.mysite.com)，它可以访问来自 mysite.com（数据库）的数据。在 mysite.com 上，我们的用户将能够创建连接的应用程序，该应用程序将提供客户端 ID + 机密 - 授予对其帐户的访问权限（完整范围？）。

根据我的研究，下一步似乎是设置一些东西来实际提供要传递给 api 的不记名令牌 - 我一直倾向于 oAuth2，但后来我读到 oAuth2 不提供身份验证。基于此，我认为我需要 OpenID Connect 才能提供用户令牌，因为我的 API 需要根据用户上下文限制数据。

在这种方法中，我的理解是我需要一个身份验证服务器 - 所以有几个问题：

• 我可以安装哪些软件来充当 OpenID Connect/oAuth2 身份验证服务器？

• 是否有特定的 Amazon Web Services 将充当 OpenID Connect/oAuth2 身份验证服务器？

• 我假设流程是：应用程序使用客户端 ID + 秘密向身份验证服务器发出请求并接收访问令牌。访问令牌可用于进行 API 调用。这些令牌存储在哪里（我假设一个特定于我正在使用的服务/软件的数据库？）

• 在进行 API 调用时，我会传递不记名令牌和用户令牌吗？

非常感谢任何见解。

Answer 1

你的理解离现实并不远。 假设您有两台服务器，一台用于身份验证，这台负责根据 Authorization Basic 和 base64 编码的 CLientID / ClientSecret 组合生成令牌。这基本上是应用程序身份验证。如果您还想添加用户数据，只需在帖子正文中传递用户名/密码，在服务器端进行身份验证，然后向令牌添加更多数据，例如用户名、声明、角色等

您可以控制放入这些令牌中的内容，如果您使用 JWT（Json Web 令牌）之类的东西，那么它们只是 json 位数据。

然后你有一个资源服务器，你用一个授权承载和你从授权中获得的令牌来访问它。

最初，代币不会存储在任何地方，它们会在您控制的一段时间内发行。但是，如果您真的愿意，您可以做其他事情并将它们存储在数据库中。不过，过期更安全，即使有人拿到它们，它们也不会长时间可用！在我的例子中，我使用了 30 分钟来验证令牌的有效性。

现在，您尚未指定要研究的语言/框架。如果您使用 dot net 之类的东西，请查看 IdentityServer，第 4 版适用于 Dot net core，第 3 版适用于以下任何内容。

如果你有兴趣，我也有一篇关于这个主题的很长的文章：

https://eidand.com/2015/03/28/authorization-system-with-owin-web-api-json-web-tokens/

希望所有这些都能澄清您的一些问题。

-- 添加以回答 cmets 中的问题。

令牌包含资源服务器正确验证它们所需的所有信息，您无需为此将它们存储在数据库中。正如我已经说过的，您可以存储它们，但在我看来，这会降低它们的安全性。不要忘记您可以控制令牌中的内容，以便您可以根据需要添加用户名。

想象一下这种情况，您希望在对授权服务器的同一调用中对应用程序和用户进行身份验证。以标准方式执行 OAuth2，这意味着首先根据客户端 ID/客户端密码对应用程序进行身份验证。如果通过，那么接下来进行用户身份验证。将用户名或用户 ID 添加到您生成的令牌以及您需要的任何其他信息中。这意味着资源服务器可以安全地假设在令牌中传递给它的用户名已经被身份验证服务器验证过，否则一开始就不会生成任何令牌。

我更喜欢自己将这两个分开，这意味着让 AS（授权服务器）来处理应用程序级别的安全性。然后在 RS（资源服务器）端，你有一个像 ValidateUser 这样的端点，它负责用户验证，之后你可以做任何你需要的事情。选择我认为更适合您的项目的那个。

最后一点，始终确保您的所有 api 调用（AS 和 RS 都只是 apis）是通过 HTTPS 进行的，并且永远不会通过 GET 调用传输任何重要信息，这意味着 URL 可以被拦截。标头和 POST 正文都通过 HTTPS 加密和安全。

我相信这应该可以解决您的两个问题。