混淆 Laravel 护照 API 安全性的工作原理 [英] Confusing how Laravel passport API security works
问题描述
客户端向服务器发送用户名和密码.
Client sends username and password to the server.
服务器然后检查此用户是否通过身份验证.
Server then checks if this user is authenticated.
如果是，服务器返回客户端的访问令牌...
If yes, the server returns an access token for the client...
然后用户可以使用这个访问令牌来访问受保护的资源...
Then user can use this access token to access protected resources...
这里的优点是我们不会通过 API 调用发送用户信息，并且访问令牌不会持续很长时间，因此黑客将无法找到用户身份验证信息(用户名和密码)，如果他发现了，访问令牌将不会持续很长时间，无法对其进行任何操作.
The advantage here, is that we are not sending user info via API calls, and the access token will not last for long time, so hackers won't be able to find out user authentication info (user name and password), and if he finds out, the access token won't last long enough to do anything with it.
这就是我对 Laravel 护照 API 安全性的理解.
That's how I understand Laravel passport API security.
这里令人困惑的是，在第一次 API 调用时，用户必须发送用户名和密码，因此黑客仍有很大机会找到用户信息！！！
The confusing thing here, is that on first API call, user has to send user name and password, so hacker still have big chance to find out user info!!!
我知道我的理解有问题，这就是为什么我感到困惑，任何解释都将不胜感激.
I know that there is something wrong with my understanding, and that's why I get confused, any explanation would be very appreciated.
推荐答案
必须有一种方法可以向授权服务器证明你的身份，一种方法是提供用户名和密码.只要使用 HTTP，您将在授权服务器和客户端应用程序之间实现通信的方式完全取决于您.如 RFC-6749 所述:
There must be a way to prove your identity to authorization server, and one way is to provide username and password. The way you're gonna achieve communication between authorization server and your client application is totally up to you as long as it uses HTTP. As stated in RFC-6749:
此规范旨在与 HTTP ([RFC2616]) 一起使用.这通过 HTTP 以外的任何协议使用 OAuth 超出范围.
This specification is designed for use with HTTP ([RFC2616]). The use of OAuth over any protocol other than HTTP is out of scope.
当然，我们始终建议尽可能使用 HTTPS.仅仅因为文档中提到了 HTTP，并不意味着 HTTPS 不能使用，因为 HTTPS 只是 HTTP 的加密版本.
Of course it's always advised to use HTTPS whenever possible. Just because HTTP is mentioned in document, doesn't mean HTTPS cannot be used because HTTPS is just encrypted version of HTTP.
我想提的另一件事是，您不需要提供用户名和密码，例如，您可以提供多种授权类型，而不是用户名和密码您可以提供client_id和client_secret，用于客户端凭据授予类型.
Other thing I wanted to mention is that you don't need to provide username and password, there are several grant types where you can, for example, instead of username and password you can provide client_id and client_secret which is used in Client Credentials grant type.
如果您对此不熟悉，我相信这对您来说有点令人困惑.向您总结 OAuth2 的目的(据我所知)是:
If you are new to this I believe this all is little bit confusing for you. To summarize the purpose of OAuth2 to you (as far as I get it), is:
- 将客户端(可以是浏览器、移动设备等)的角色与资源所有者(通常是帐户所有者)分开.为什么?因为如果没有分离，客户端就可以访问用户的敏感数据.
- 想象一下，第一点对于通信来说足够安全.但是，如果有人掌握了您的会话，会发生什么?他们可以访问所有人！这就是 OAuth 引入范围的原因，根据范围，用户提供的访问令牌对资源的访问权限有限.范围可以是读、写、共享等——这个实现取决于开发者.因此，如果有人拿到了您的访问令牌，由于范围的原因，他们对资源的访问权限有限.
- To separate role of the client (which can be browser, mobile etc.) from the resource owner (usually the owner of account). Why? Because if there is no separation, the client has access to user's sensitive data.
- Imagine that the first point is secure enough for communication. But what happens if someone gets their hands on the session you have? They have access to all! This is why OAuth introduces scopes, where depending on the scope user has with provided access token has limited access to resources. Scope can be read, write, share etc. - this implementation is up to developer. So if someone gets their hands on your access token, because of scope they only have a limited access to resource.
这些是我的原因之一，而 RFC-6749 有更好的解释:
These are one of my reasons, while RFC-6749 has better explanation:
- 需要第三方应用来存储资源所有者的凭据以供将来使用，通常是密码明文.
- 服务器需要支持密码认证，尽管密码固有的安全弱点.
- 第三方应用程序获得对资源的过于广泛的访问所有者的受保护资源，使资源所有者没有任何限制持续时间或访问有限子集的能力资源.
- 资源所有者无法撤销对单个第三方的访问权限不撤销对所有第三方的访问权限，并且必须通过更改第三方的密码.
- 任何第三方应用程序的入侵都会导致最终用户的密码以及受该密码保护的所有数据密码.
要了解有关 OAuth2 的更多信息、授权类型和用途，我建议您阅读以下内容:
To learn more about OAuth2, it's grant types and purposes, I recommend you to read this:
- OAuth 2 简介
- 提到了 RFC-6749，尽管由于以下原因可能难以阅读技术写作.
- An Introduction to OAuth 2
- Mentioned RFC-6749, even though it can be difficult to read because of technical writing.
希望我至少澄清了一小部分模糊.
Hope I clarified at least a small piece of blur.
这篇关于混淆 Laravel 护照 API 安全性的工作原理的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
