joselfonseca
commented
4 years ago Hello @nckhell and thanks!
So this is a big topic we've been discussing a lot internally where I work and this is what we've come up with so far.
-
We use this package mostly for native apps that use keychain to store this tokens so we don't worry about that there too much.
-
In Web we don't really use this as a primary way to get tokens, We are now using Laravel's built in authentication and then using this method for the front end https://laravel.com/docs/6.x/passport#consuming-your-api-with-javascript since our SPA will leave in the same code as the laravel app. This allows us to have just one container that we deploy with the app and we can scale it to many containers and just balance the traffic.
If you are going to use this method in web i think you have to consider those other options. I would give the article a read later in the day and see what we can do about it or if there is something that can be added
Hi,
Fitst of all: I love the package, great work!
I have a question regarding storage of the tokens in a frontend setting. It is bad practice to store them in localStorage for security reasons. A safer way is to store the refresh token in an httpOnly cookie (see http://esbenp.github.io/2017/03/19/modern-rest-api-laravel-part-4/ for reference). Currently the package does not take use of this
Are you planning to support this mechanism or is it easy enough to extend the functionality of the current package to start supporting this? For the latter: what would be the best way to do this?
Context: I’m building a headless frontend app that will make use of a GraphQL endpoint to authenticate users (built with laravel). I’m concerned with the vulnerability of storing tokens in localStorage so I’m exploring alternative solutions.
Thanks!