Be part of JetBrains PHPverse 2026 on June 9 – a free online event bringing PHP devs worldwide together.
I'm building a Laravel system which consumes all data, including user authorization, from an external API. I have complete control of the API. There is no local database. In doing so, I'm trying to use as much as Laravel's scaffolding as possible.
I've successfully built a custom authentication service provider and user provider however I have run into issues. For instance, Laravel's default UserProvider uses GenericUser for retrieveByCredentials() which doesn't support CanResetPassword out of the box.
This has got me wondering: should I even leverage Laravel's User model if everything is coming from an API? Should I create my own custom CustomUser model? What are the pros/cons/best approach?
I guess I'm just looking for some general suggestions on an approach, before getting too deep. Thanks!
I don't understand your confusion. You've built a custom authentication service provider but you expect a built-in password reset to work. I'm probably missing the point here? My best guess is that you haven't implemented everything in your auth service provider and that is why password reset is not working.
@bugsysha I guess what I'm confused about is why Laravel's built-in authentication scaffolding works for everything except password reset.
For instance, my custom user provider retrieveByCredentials()
HIS WORKS FOR PASSWORD RESET BUT NOT LOGIN
return new \App\Models\CustomUser([
'id' => $credentials['email'],
'email' => $credentials['email'],
'remember_token'=> 'test',
'password'=>'foo',
]);
// THIS WORKS FOR ALL OF LARAVEL'S AUTH SCAFFOLDING, EXCEPT PASSWORD RESET
return new GenericUser([
'id' => $credentials['email'],
'email' => $credentials['email'],
'remember_token'=> 'test',
'password'=>'foo',
]);
@dietcheese Why? This is just going to make the consuming application slow as a dog as it has to do multiple API calls to check the authenticated user, their permissions, etc. Congratulations. You now have an application that instead of doing this in microseconds via a database, will not take significantly longer because it’s going network calls instead.
@martinbean from what I understand, once the user is authenticated, the necessary information can persist via session (token,etc). Even if it were database-backed, hitting the database unnecessarily would create overhead, no?
from what I understand, once the user is authenticated, the necessary information can persist via session (token,etc).
@dietcheese The user is looked up once per page load. Only the identifier is stored in the session.
Even if it were database-backed, hitting the database unnecessarily would create overhead, no?
Executing a database query is much, much faster than a network call. Once you’re connected to a database, that connection can be used for multiple queries in that request. The same can’t be said for network calls. A network call is literally the slowest communication method you can pick.
Network calls can also fail: servers can be down, connections can be congested, etc.
@martinbean I understand the advantages of using a local database, but as originally stated, that's not what I'm doing. I'm sure it's possible to persist a login via sessions since it's common practice, I just don't know how Laravel handles it. If you have any suggestions in that regard, I'd love to hear them.
@dietcheese Suggestions on what? If you want to know how Laravel works, read the source code. It’s open source.
Don’t start making bonkers, network-based authentication and authorisation layers just because you don’t really know how the default session-based driver works.
Please or to participate in this conversation.