混淆 Laravel 护照 API 安全性的工作原理

Posted 2023-03-15

【中文标题】混淆 Laravel 护照 API 安全性的工作原理

【英文标题】：Confusing how Laravel passport API security works

【发布时间】：2018-09-15 02:31:35

【问题描述】：

客户端向服务器发送用户名和密码。

服务器然后检查此用户是否已通过身份验证。

如果是，则服务器为客户端返回一个访问令牌...

然后用户可以使用此访问令牌访问受保护的资源...

这里的好处是，我们不是通过 API 调用发送用户信息，并且访问令牌不会持续很长时间，因此黑客将无法找到用户身份验证信息（用户名和密码），如果他发现了，访问令牌将不会持续足够长的时间来做任何事情。

这就是我对 Laravel 护照 API 安全性的理解。

这里令人困惑的是，在第一次 API 调用时，用户必须发送用户名和密码，所以黑客仍然有很大的机会找出用户信息！！！

我知道我的理解有问题，这就是我感到困惑的原因，非常感谢任何解释。

【问题讨论】：

使用 https 减少被黑的机会

【参考方案1】：

必须有办法向授权服务器证明你的身份，一种办法是提供用户名和密码。只要它使用 HTTP，您将在授权服务器和客户端应用程序之间实现通信的方式完全取决于您。如RFC-6749中所述：

本规范设计用于 HTTP ([RFC2616])。这 通过 HTTP 以外的任何协议使用 OAuth 超出范围。

当然，我们总是建议尽可能使用 HTTPS。仅仅因为文档中提到了HTTP，并不意味着HTTPS不能使用，因为HTTPS只是HTTP的加密版本。

我想提到的另一件事是，您不需要提供 用户名 和 密码，您可以使用多种授权类型，例如，代替username 和 password 您可以提供 client_id 和 client_secret 用于 Client Credentials授权类型。

如果您是新手，我相信这一切都会让您感到困惑。总结一下 OAuth2 的目的（据我所知）是：

将客户端角色（可以是浏览器、移动设备等）与资源所有者（通常是帐户所有者）分开。为什么？因为如果没有分离，客户端就可以访问用户的敏感数据。 假设第一个点对于通信来说足够安全。但是，如果有人掌握了您的会话，会发生什么？他们可以访问所有人！这就是 OAuth 引入范围的原因，根据范围，用户提供的

访问令牌

对资源的访问是有限的。范围可以读取、写入、共享等 - 此实现由开发人员决定。因此，如果有人拿到了您的

访问令牌

，由于范围的原因，他们只能有限地访问资源。

这些是我的原因之一，而RFC-6749 有更好的解释：

需要第三方应用程序来存储资源 所有者的凭据以供将来使用，通常是密码 明文。 服务器需要支持密码验证，尽管 密码中固有的安全漏洞。 第三方应用程序获得对资源的过度访问权限 所有者的受保护资源，使资源所有者没有任何 限制持续时间或访问有限子集的能力 资源。 资源所有者不能撤销对单个第三方的访问权限 无需撤销对所有第三方的访问权限，并且必须通过 更改第三方密码。 泄露任何第三方应用程序都会导致泄露 最终用户的密码以及受该密码保护的所有数据 密码。

要了解有关 OAuth2 的更多信息，它的授权类型和用途，我建议您阅读以下内容：

An Introduction to OAuth 2 提到了RFC-6749，尽管它可能因为技术写作而难以阅读。

希望我至少澄清了一小部分模糊之处。

【讨论】：

是的，你清除了一个很好的模糊部分，但请帮助我确定我是否正确理解了你。 [代替用户名和密码，您可以提供 client_id 和 client_secret ] 但是黑客仍然可以获取这些数据，如果他得到它们，他可以为他请求访问令牌！！！ [所以如果有人拿到了你的访问令牌，由于范围的原因，他们只能有限地访问资源。]但是如果他拿到了所有者的访问令牌，那么他就会造成真正的损害！！！

我可以从您的回答中得出以下结论：当用户向服务器发送第一个请求以获取访问令牌时，oAuth 无法保护我免受黑客和入侵者的侵害，因此我应该将 https 与第一次请求保护它！我可以跳过在其余请求中使用 https 以获得更好的性能，因为它们将受到 aouth 的保护。我只是想确保我理解你的解释，所以请告诉我我的结论是否正确......

是的，有点。 OAuth 不用于安全通信，该角色上升到 HTTPS，OAuth 只是验证用户的另一种方式。您可以进行基于表单的身份验证，如果不使用 HTTPS，它仍然不安全。

引入 OAuth 的主要原因是因为在某些时候，需要一个应用程序（Web 应用程序、移动应用程序、桌面应用程序等）需要访问不属于域的资源到应用程序。需要将资源所有者与需要处理数据的客户端分开，而 OAuth 解决了这个问题。

为了清楚起见，我们以 facebook 为例。有第三方网站，他们希望能够使用 facebook 在他们的网站上拥有帐户（使用 facebook 选项登录）。使用该选项后，您可以清楚地看到他们访问了您的个人资料数据，因为您已经确认，您提供了范围。在这种情况下，那些第三方网站是想要从facebook访问资源的客户，但他们必须与资源所有者区分开来，因为他们不是，所以他们的访问范围受到限制。