Laravel Passport machine-to-machine API authentication - laravel

I have an app installed on many sites. There are two parts to the app: a dashboard for admins and a front end for visitors.
The admin dashboard consumes my Laravel API flawlessly when a user is authenticated via the Laravel Passport auth API. I need the front end app to communicate with the Laravel API anytime a visitor (non-admin/not logged in) loads the front end.
The problem is authenticating the front end API request to only allow interaction with the correct organization's records.
How do I get Laravel Passport to create an API key based on a logged in user, return it to the admin, and authenticate some requests using this API key?
Using Angular 9 for the admin and front end apps, Laravel 7 for the API

I ended up switching to Laravel Sanctum for this project because it is more suited for this kind of project.

Related

how user get token for subsequent request after loging in particular app by Google account

I'm a newbie in web development. Currently, I've learnt laravel framework and be researching about passport and socialite. I'm being stuck that after logging in the application successfully by their Facebook account how users get the access token for subsequent requests.
This has been implemented using Laravel Socialite. You can follow each step to implement Laravel Socialite.
You will get the information on how to create Secret Key & Access Key for social login.
https://github.com/jd-patel/laravel-social-login

Laravel Fortify login only if user is admin

I have two table users and role and I need to log in using Laravel fortify only if user role is admin or showing error. I tried to do that using middelware, but i need to add the condition: If the user is not admin, he cannot log in.
You can read at laravel docs:
https://laravel.com/docs/8.x/fortify#laravel-fortify-and-laravel-sanctum
Some developers become confused regarding the difference between Laravel Sanctum and Laravel Fortify
And:
If you are attempting to manually build the authentication layer for an
application that offers an API or serves as the backend for a single-page
application, it is entirely possible that you will utilize both Laravel Fortify
(for user registration, password reset, etc.) and Laravel Sanctum (API token
management, session authentication).
Then you want to check role of user, you should use Laravel Sanctum

In which cases using of laravel passport gives some advantage?

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.

Which OAuth2 Grant to use when developing SPA, Mobile App with Laravel as backend. Will not be using third party login

I'm developing a mobile app + SPA using Laravel as a web service. I'm not sure which grant flow will be good for this. I would avoid any third party login like facebook, google, etc. Id'like to handle user login simply with email and password. I want user to login only once on mobile app.
I had gone through some articles. I'm very confused. I found out 2 flows which might work here. 1st is implicit Grant & 2nd one is password grant.
If SPA is built inside your Laravel project you can handle user login simply with standard laravel authorization method.
For external use (mobile app or external SPA) you should authenticate users with API.
Laravel Passport mainly offers two way to handle this.
Personal Access Token
Fresh API Token
I suggest using the second one cause is the "Standard way" to consuming your web app with a nonsecure source.

Lumen Socialite authorisation flow

Info
I'm looking for some clearification for using the Socialite package in a Lumen project. I want to use OAuth2 so users can authenticate with theire Google, Facebook or other social account on our applications.
To my understanding Socialite redirects to a page of the selected provider, asks the user for permission and return to the application with the authenticated user object. I made a base setup with a Laravel application and this all works fine.
The problem
I have an authentication API (Lumen based) where user credentials are validated. This is only a backend service. The actual user credentials are received from different front-ends (applications). Do the frontends need to implement OAuth2 / Socialite and send the social user details to my authorisation API or can the API arrange the whole OAuth2 process?
I don't quite get it how the redirection should take place in an if the whole flow is arranged by the API? There is a stateless() option available in socialite and i found some information where socialite is used in Lumen but then i don't get the whole redirect / authentication flow.
Options
Different optios
Like to hear from users if this option is possible, hope my question is clear. :)
Just to update on my own question;
After some research i found the flow to be like this:
-> Frontend handles the user request to be authorised by Oauth2 with a specific provider. (we get redirected to a page of the provider asking about permission for this application). This can be done with socialite (in case of Laravel) or any other package for a specific framwework.
-> An Access token is received by the frontend and send to our Lumen backend service. Here we can use Socialite again to get the user details for this access token. The user details can then be used to create a new user or attach a social login to an existing user. When access token is valid and user is created or found in existing user, the user can proceed in the application.
Hope to help someone in the future with the same questions :)

Resources