I have a Vue SPA hosted on one domain and a Laravel back end on another domain. I use Sanctum and Fortify to manage authentication to the application. I have implemented the Fortify registration process in my application and that is working fine. I would now like to make the registration process by invitation only.
My thinking was to send an invitation email to the user from Laravel with with a temporary signed URL with an expiry period. This would point at the SPA rather than a Laravel endpoint and the SPA could then validate the link by calling Laravel using the existing signed middleware, check the expiry time and so forth. If all that was valid I would let the user provide his password credentials, locking the email to the value hashed in the link and use the standard Fortify registration process to complete the registration process.
Looking through the Laravel codebase, the only way I can see of doing this is by cloning and modifying the temporary signed URL functionality and changing it to use the base URL of my SPA and hard coding a specific link to the registration page of my SPA. Not the most elegant solution so before I embark on doing that I wondered if anybody had experience of doing something similar and had a better, more elegant approach or any pointers on this?
Related
Back Story:
I recently got into Web Development, and I would really appreciate it if you guys could share some great material/tutorials where I could learn, already got a couple of Udemy courses, and searched online but I still have some concerns.
For the first project, I would like to create an App which would be SPA. This would be a basic To-Do App, where users could log in and add To-Dos to their list.
Issue/Question:
How could I implement logging-in functionality only with Social Accounts (No regular Email/Password method)? If the user uses the login feature for the first time he is registered/added to the database where his data is stored, and for the second time, he would log in and fetch the data accordingly. I was thinking of Laravel Socialite, although, I'm not sure if it is used for SPA (Login without reloading/redirecting) pages? And if it is, do I need any additional forks/plugins?
I have found Universal Social Auth for that, however, I'm not sure if it does exactly what I need, and how to implement/configure it correctly.
All in all, I would really appreciate it if you guys could share some light here and perhaps share some tutorials or articles about that as well.
Backend:
Laravel
Frontend:
VueJS
VueX
VueRouter
Vue I18n
Axios, Vue-Axios
You need Laravel Socialite to get data about user from the identity provider (it could be Google, Github, Facebook or something else). It will use Oauth2 protocol.
You will store client_id and client_secret from the third party authentication you want to use. User will click for example Sign up with Google and it will redirect him to Google login page. If he fills correct username and password you will get his user information by using Socialite::driver('github')->user() .
You can use updateOrCreate() method to create user if it doesn't already exist in your database or just to update his data. Email or username fields could be identifiers or whatever is unique and works for your case.
After you found the user in database or created a new one, you should log in him to your application using session cookie or some kind of token.
Whole auth proccess is happening on the backend side, only when you successfully log in user to your app you can issue cookie to the frontend Vue side. So to answer your question, yes you can use Socialite with SPA.
Don't mix Laravel Socialite/Oauth2 with authentication proccess/Laravel Sanctum.
Former is for retrieving user data without registering on your site. Latter is for actually giving access to your API for specific user.
I am planning a small project and have a question about authentication. I would like to implement the site with Laravel 8. However, as soon as the user has successfully logged in, he should be directed to the user dashboard. The User Dashboard should be a pure VueJS Single Page Application.
Now my question. Which auth should I use here? Session or token for the whole site or is both possible and useful?
If I use the token auth variant, for example, then I can protect the Vue app very well but I cannot access the user information outside the Vue app. For example, the current profile picture of the user should appear in the navbar and not only in the vue app but also on the landing page, contact page etc.
How can I do this and what will be the best practice and thanks for your help!
Use token based Authentication
(Laravel Passport)
Use Token-based authentication system.
In this way, you'll be able to manage the entire application UI and role checking in the frontend only. I would rather prefer to go with JWT [https://jwt-auth.readthedocs.io/en/develop/laravel-installation/]. It's easy to use and the documentation is pretty good. It's even supported by Lumen also. If you wish to integrate any micro-service in your application future, then it's available in Lumen micro-service also.
I have created an application with Laravel 7 that contains users that can log in.
In parallel, I create a showcase site for the application (another domain) and essentially html/css.
I would like on this showcase site to propose login and registration buttons if there is no user connected to the laravel.Otherwise I would just like to propose a "Dashboard" button if a user is connected to the Laravel application.
How to do that? I confess that I'm a bit lost. Thanks for your help.
You need to create an API on the laravel app which will be used by the "showcase site".
To login and authorize themselves you can use JWT
to keep user data and use it on the showcase site you can either save them in
localstorage (just be careful not to save any sensitive data there as people can take that information in case of XSS vulnerable)
indexdb
cookies
None of these methods are safe. They can be exploited using XSS so i advice on using JWT to secure sensitive data.
I'm building a SPA using Vuejs and consuming Laravel API's, and users can have multiple roles, what is the best way to save token and user roles? as well as prevent users from knowing what the roles are?
There is one solution I know yet, which is to save them in Cookies and LocalStorage.
However, if someone knows my LocalStorage key for the roles and they were just like a normal user and changed it, so that they can see what Admin Dashboard looks like (Just the Front-End) and what Admin can see in the app.
How can I prevent them? and what are the best ways to secure SPA?
Thank you in advance.
You can never consider SPA frontend as "secure". If something is executed on browser it means it can be modified by user. It of course doesn't mean SPA is bad, no no, just it is not good solution for every project.
If You want to be sure that user will never see admin dashboard then it should be in separate bundle or even better - separate project.
Instead - consider migrating SPA to SSR (in Vue You can use Nuxt.js (https://nuxtjs.org/) for this).
Thank's to this user will receive only HTML response (just like in Laravel with Blade). Because of this You can authenticate user and check roles BEFORE user will receive any content (and block access to admin panel by that).
BUT - if You are using Laravel with Vue in same project (so Vue is initiated by Blade) this means You can just like in Nuxt check user before it will receive any content. Just make middleware for it. But it will help only by blocking entire page, and not for changing (in secure way) content on single page based on multiple roles. So again - You need SSR for that.
For any every solution I would suggest You to use new official library from Laravel - Sanctum (https://laravel.com/docs/7.x/sanctum).
Laravel API use role and permission to check user is can do something.
Client save jwt token and use jwt to authen Laravel API. You will get user info in laravel side. Use user id check in role table.
I read https://laravel.com/docs/6.x/passport now and it is clear technically, but in which cases have I to use it to get
advantage comparing with laravel native auth or jwt/auth I worked before?
1) In config/auth.php 'guards' we set which auth driver would be used in the app
and it can be only 1 set. I mean we can not set passport and jwt/auth in 1 app?
2) Looks like passport can be used in case when we use blade page and form is submitted as we do in blade page as :
<form method="POST" action="{{ route('register') }}">
#csrf
I suppose there is no difference in blade forms definition using passport intead of native auth?
3) Also, passport can be used instead of jwt/auth in backend rest API and there is no difference in work of clients app
using this backend rest API ?
4) Is passport better/has some advantage in both cases or it is just one more replacement?
5) Please give some examples in which passport can be used / got advantage of using it may be in some other app types?
Thanks!
Laravel Passport is a Laravel package that allows you to integrate the OAUTH2 protocol into your application.
This means that when you want other services to retrieve user data from your application, or add data, they can request access for users. Users can give permissions for certain actions by clicking a button on the external site, logging in on their account on your Laravel site, and allowing access for the external service. Users are then redirected back to the other website, and after a few requests between the two servers, the external service now has the requested permissions to read or alter user data. This protocol is almost always used whenever you click "sign on with ..." since all large social media platforms have OAUTH2 integrations.
To answer your questions:
I believe this question: Laravel combine Passport authentication and normal authentication will answer your question.
Passport sits on top of default Laravel auth and needs this to authenticate requests. So users still have to have an account on your site to allow other websites to access your account.
There are big differences in how normal API auth works, and how Passport works. The biggest difference is that normal API auth should only be used for your site, not for external sites to fetch user data from your API. With OAUTH2, users can give certain permissions to websites, and using tokens, these external sites can perform certain actions on your site.
If you want to allow other sites to fetch account information from your site, you should implement Passport, if not, then using Passport has no large advantages.
Examples are things like Sign in with Google, or with Facebook, Twitter or GitHub, Even stackoverflow has an OAUTH2 implementation. Services can, for example, create new Facebook posts for a user, request all twitter posts from the last year or create a new issue in Github.