混淆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:
- 需要第三方应用程序来存储资源 所有者的凭证供将来使用，通常是密码 明文.
- 尽管服务器仍然需要支持密码身份验证 密码固有的安全性弱点.
- 第三方应用程序获得对该资源的广泛访问 所有者的受保护资源，从而使资源所有者一无所有 限制持续时间或访问有限的子集的能力 资源.
- 资源所有者无法撤消对单个第三方的访问权限 而不撤消所有第三方的访问权限，并且必须这样做 更改第三方的密码.
- 任何第三方应用程序的破坏都将导致以下方面的损害: 最终用户的密码以及受该密码保护的所有数据 密码.
- Third-party applications are required to store the resource owner's credentials for future use, typically a password in clear-text.
- Servers are required to support password authentication, despite the security weaknesses inherent in passwords.
- Third-party applications gain overly broad access to the resource owner's protected resources, leaving resource owners without any ability to restrict duration or access to a limited subset of resources.
- Resource owners cannot revoke access to an individual third party without revoking access to all third parties, and must do so by changing the third party's password.
- Compromise of any third-party application results in compromise of the end-user's password and all of the data protected by that password.
要了解有关OAuth2(授权类型和用途)的更多信息，建议您阅读以下内容:
To learn more about OAuth2, it's grant types and purposes, I recommend you to read this:
- 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屋！
