I have a Laravel 5.5 Application that's using the session based auth out of the box. On some of these pages I have react components that need to get/post data from/to an API.
What is the best practice for handling this? Do I simply hide the API endpoints behind the auth? This would work but should I be using Laravel Passport for this instead?
I've had a play with Passport and it seems that this would work but I don't need users to be able to create clients and grant 3rd party applications permission etc. There is just the first party react app consuming the data from inside the laravel application (view).
From my initial experimenting with it, it seems I'd need to have the login call made first to receive an access token to then make further calls. As the user will already be authenticated in the session is there an easier way?
I'm not sure if Passport is intended to be used for this purpose or not. I'd rather take the time to get it right now as I'd like to get the foundations right now if the app scales.
You can proxy authentication with Passport. Using the password grant type users would still log in with their username/password, then behind the scenes make an internal request to Passport to obtain an access token.
Restrict what routes are available when registering in a service provider by passing in:
Passport::routes(function ($router) {
$router->forAccessTokens();
$router->forTransientTokens();
});
That limits access to personal tokens and refresh tokens only. A client will be created when you run php artisan passport:install.
Setup a middleware to merge the password grant client id and secret in with the request, then make a call to the authorization endpoint. Then it's just a matter of returning the encrypted token and observing the Authorization header for requests to your api.
Related
I am currently using a API to validate Login Credentials.
I have gotten to the point where I am sending username/password correctly.
This API will return a bolean, depending on if those credentials are correct.
Along with the entire user's information, including their address etc.
How can I correctly store this into Laravel Auth, so I can use Auth::user etc in blade?
I do NOT have Database access, only API access to validate user login details.
I cannot create a local - Laravel database, as this application has to be completely API based.
I am using Guzzle to query the API.
You should try using JWT for authentication, implementing your own API Authentication can cause some security issues if not done right.
Also JWT for Laravel already has support for Laravels Authentication system
I'm trying to implement laravel's passport to protect my api routes and I have a case where the route should be inaccessible unless it is called by an authorized application. I am trying to use Client Credentials Grant Tokens and using postman I am able to generate an access token, which then I can use for access authorization.
The problem is - I don't understand how should I safely use this with Vue and axios. I have my component in which I need to call this api, I can of course set a form body including all the necessary fields (client_id, client_secret and grant_type) but that would mean that anyone could just open up chrome dev tools and search for client_secret in the source and they would get the hardcoded client secret, which would grant them access to the api. What is the right way to do this?
It depends on how you use your Vue frontend.
If it is a frontend mostly for your own site, but sometimes needs to access an external API, than you should have your backend make the API calls and store secrets there.
If you are developing a Vue frontend dedicated to the external API, but running on a different domain, you could go for the PKCE option: https://laravel.com/docs/8.x/passport#code-grant-pkce
If you have a frontend on the same domain as the API, use the CreateFreshApiToken option provided by Laravel passport.
I've created a web application that uses the built-in authentication method for the web, once the user is authenticated he/she is presented with a dashboard page. At this moment Ajax calls to an API need to be made to fetch data for the logged-in user. What would be the correct approach to this to make it is secure?
As a next step, I would like to be able to use the API "stand-alone" as well, so a 3rd party could access the dataset through the API as well.
Right now I am looking into Laravel Passport as well as Spatie Permission package to help me with access control.
If you are using ajax calls in same domain it won't be problem with built-in authentication to give access to authorized users only, because tokens & sessions are accessible for laravel and you can get authenticated users by default.
If you want to make external api as well the best approach will be to use Laravel Passport and pass token in Authorization header as usual.
Hope this helps you
I'm using Laravel Passport password grant type to enable my mobile clients(Android, iOS ...) to generate an access token. My mobile clients cannot use oauth/token route to get access and refresh tokens themselves, because it uses web middleware (as I understand). My questions is,
Should I make request to oauth/token myself in server by passing data mobile clients posted? If I do this how do I bypass web middleware. (Manually creating a dummy user and using it to bypass web middleware is not that I want and weird solution)
In my particular case I always this by removing \Illuminate\Session\Middleware\AuthenticateSession::class from the web middlewareGroup on app/Kernel.php.
I'm also using laravel-cors to allow Cross-Origin Resource Sharing headers. My apps are API only and the clients are external (both mobile and web clients are external) and they all authenticate and renew tokens themselves interacting with the Passport routes.
I'm thinking to develop a full-fledged Identity System in Laravel 5 with Passport.
Following is my requirement:
I should have main identity management app like identity.mysite.com where all of my users are stored.
I have 2 other applications APP1, APP2.
When user request restricted resource on APP1, (s)he should get authenticated by identity.mysite.com
Once authenticated, let user access resources on APP1
Meantime, if user decided to access restricted resources on APP2, (s)he should not be asked to put credentials again.
Things I've tried:
simpleSAMLphp - SAML is an option which does these things for me. But it is not as mature as OneLogin and I'm not thinking to go in SaaS model at this stage unless it is necessity.
Laravel Passport - oAuth 2.0 seems tempting. I can even use, Passport Grant Tokens but I'm unsure on how reliable it is over SAML. Also, Laravel Passport is being widely used to authenticate API. Is it going to be useful while authenticating traditional session based apps? I haven't seen any example where the proper SSO is implemented with more than one application and laravel passport.
I know OAuth 2.0 is not an authentication protocol. Rather it uses something called Authorization but we probably can make it work to support Authentication protocol as mentioned here. Is it something, that Laravel passport supports?
This is what I call a resource oriented approach where all the clients(app1, app2...) want to know weather requesting user is authorized to access the resource or not...
Here we need to shift all the authenticating logic to oauth and make all our requesting apps dependent on OAuth. This way if user request app to access resources then if:
Token is present then app will request oauth server to validate given token and if found true then app will provide access to user.
If token is not present then you can solve it by asking for credential and app will transfer user data to oAuth server and validate it respond with the token.
As per my experience I use to implement this approach and I think Laravel Passport is an abstraction layer over top of your authenticating system. You can mold it however you need. There are few more enhancement and advancement can be done but this would work as a basic layer over top of your SSO.
You can achieve this with passport however you are right about the examples as there are not many or lacking on some steps.
You could to create a new middleware in App1 and App2 side that communicates with identity.mysite.com and gets the user data (token, scopes, etc, id) then it will verify if the token is valid.
On the passport server side you need an endpoint to return whether the token is valid or not and any additional info.
To avoid making too many requests to your passport server i would recommend to create a service that get the TTL of the access token and set it as the time on cache on App1 or App2 for the user data.