Confusing how Laravel passport API security works

Question

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...

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.

That's how I understand Laravel passport API security.

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.

Answer 1

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:

This specification is designed for use with HTTP ([RFC2616]). The use of OAuth over any protocol other than HTTP is out of scope.

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.

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.

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:

• 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.

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.

To learn more about OAuth2, it's grant types and purposes, I recommend you to read this:

1. An Introduction to OAuth 2
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.