I am developing a web application in Laravel. Now I'm in the process of creating an android app. I need to create a web service (back end) in Laravel, but I don't know how to manage the sessions (auth) in the request.
My idea is to create a unique token for every session, and store it in a database. So, every request need the token be included, and my backend will check if the token is valid or not.
How can I modify the login functionality that comes with Laravel 5.0 to create an return the token?
I read the documentation and some articles in the internet, but it is still not clear to me.
You can create a token during registration of the app which should correspond with the user id. This token will be used together with the user id anytime you call any of your api's to authenticate the user.
You can create a filter named custom_authentication and check for the token validity inside that filter. Now just apply this filter before every routes, which you want to be authenticated.
Using only simple authentication token is not very secure, you need to go with HTTPS always.
If you want to make the API secure with HTTP, you might have to implement OAuth with the help of packages like this.
Related
I am building a Vue app that uses pure PHP (no PHP framework) for its back-end. For my authentication system, I thought that using jwt(JSON Web Tokens) could help me. So I searched the web and found this article and also this one to help me build a login-register system with the help of jwt. I have no problem in implementing these articles in my front-part (Vue) and back-part (PHP) of my app. Currently I can send a request when the user register to the site and send back a jwt to the front-part with the help of firebase php-jwt library.
But the main question comes here. As I know from Vue ecosystem one of the reasons that we use Vuex is to store some data (state) globally in our apps and without calling a server we could use them anywhere (or in any route) in our Vue apps.
By reading one of that two articles, I noticed that finally the jwt is stored in Vuex and when the user wants to see an authorized page (a page that needs Authorization) the Vue app checks the Vuex to see if the token exists or not and if it exists, the app allows the user to see that page.
By reading the second one I noticed that jwt is useful when the user sends request to the back-part of site. In that case jwt is decoded and if it is valid (for example the expiration date is OK or ...), the user can access to an authorized page.
With the description above what is the benefit of using jwt in my Vue app? If I store just the id and user-name of user, it could do the same task for me. In other words, If I want to ask my question clearly, the problem is when I want to use Vuex and not send request every time to the server, I don't need and can't benefit from jwt (am I right?). Similarly when I want to use jwt, I could not benefit from Vuex. Because I must send request each time to find that the jwt is valid or not and after that decide about the user.
If I understood correctly and there is a contradiction for using both jwt and Vuex, why there are so many tutorials that speak about authentication a Vue app with jwt? Also if my understanding about jwt is correct, does that mean that when the jwt is expired I must ask the user to login again and again (regardless of using or not using Vuex)?
Could anyone please help me to have a better understanding about this problem to have better decision about my authentication system?
With the description above what is the benefit of using jwt in my Vue app?
JWT is used in authentication. You could use cookie sessions if you want.
I don't think it has an impact on your app. Probably save you some few round trips if your JWT happens to contain some data you need like user id.
the problem is when I want to use Vuex and not send request every time to the server.
I am not sure how these two are related.
If you need to make a request, then why would you use Vuex?
Vuex is a state management library.
If you need to do a request, then do a request.
Vuex does not relate to JWT in any way.
If you decided to put your JWT token in Vuex then that's your decision. Some put it in browser's localStorage or cookies.
Similarly when I want to use jwt, I could not benefit from Vuex. Because I must send request each time to find that the jwt is valid or not and after that decide about the user.
There's a lot of things you can store in Vuex that you don't need to do a request first:
Global component states e.g Login/Signup modals, NavMenu, Audio/Video player
Category filters like you see in Amazon or any shop-related apps
I am not sure what you are doing that you need to send request each time to find out if jwt is valid or not.
If something needs to be done on server-side then it has to be done on server-side whether you use jwt or cookies.
Also if my understanding about jwt is correct, does that mean that when the jwt is expired I must ask the user to login again and again (regardless of using or not using Vuex)?
JWT is a format. If you use OAuth2 for example, there's "access token" and "refresh token". You can get another "access token" automatically with "refresh token" and so that might mean you don't need to show login form again.
You could also just refresh your JWT token each time if you want. I'm not sure about the implications of that but there's a lot you can do.
These links might help you:
https://stackoverflow.com/a/36932032/10975709
https://stackoverflow.com/a/45214431/10975709
My question for you is:
If you were not to use JWT and instead just use cookies, how would things differ? (Aside from the technical aspects like needing to refresh tokens)
You are probably approaching/thinking/using JWT the wrong way.
I created an API to login in my web app. After checking the parameters, use the Auth method: loginUsingId() with the id of the user to be logged in.
After that I get authenticated correctly, in fact doing an echo Auth::user() shows the user property correctly.
However, by making a redirect to another project page, I am no longer logged in the portal and shows me the login page.
It seems that the user's session does not remain or that is not created at all.
I use Laravel 5.6. I have no middleware for the route.
Each time your page accesses the API, it's essentially talking to a brand new instance of the API.
Think of it like this. Your "login" endpoint is not actually telling the API to log someone in. It's telling it to merely verify the caller's claim that the given password belongs to the given user, end of story. If you want to turn that authentication into actual "login" behavior from the UI perspective, there's other steps you need to take.
If Laravel is serving up Blade files for your site, then it's a different story. Out-of-the-box, it generates a Php session for you, and sends the session-key cookie to the browser for use in subsequent requests.
Similar to a session-key, for maintaining a session between a website and a separate API, you need each subsequent call to include a token. And you need the login endpoint to provide that token upon successful authentication.
Passport is one way to go, but it might be overkill for your situation. Passport is good for handling users, clients, and authorization permissions. But if all you want is authentication and you're not as concerned with controlling what they have access to beyond that, then I highly recommend Tymon JWT-Auth.
Both Passport and JWT-Auth use "bearer tokens" in the 'Authorization' header. There're other kinds though, like "basic tokens". A basic token is just an encoded concatenation of the username and password. Laravel supports this with a route middleware, but I do still recommend going with JWT.
One of the nice things about JWT is you can actually include extraneous data within the token itself. And it positions you better to lean into Passport (OAuth2) if/when you need it, by not requiring your client-side to change its authentication method.
I am creating a new rest API using Laravel 5.6. For API authorization, I have implemented Passport and it is working fine.
However, I want a system where anyone who wants to access any route of my API including register and login that requires token.
I am thinking in this way but not so sure how I can implement in Laravel.
I will issue one static token and will store into database.
I will encrypt that token and will provide to the client in my case
mobile app.
Mobile side the token I will store into shared preference so no one
will have direct access.
When mobile send a request to access any route of API, it has to pass the token in the header with the custom key
API will decrypt the token and match with the database one.
If it matches that will allow accessing the API.
Then later I may use the Passport token to add additional layer or security.
My question is,
How to implement this system in Laravel so I don't have to write code
for every request and all request pass through this validation?
I've set up a central app (let's call this maindomain.com), where I've setup Passport. This site will be where users register to gain access to all other apps I create.
To test it out, I've followed Matt Stauffer's blog post to create a client app that will use the user data stored on maindomain.com, let's call this app1.com.
I can confirm that my callback and whatnot work fine. When you go to app1.com/login (as per my route) it redirects to maindomain.com and allows you to authorise app1.com to use your login details - beautiful.
As per Matt's post, right now it prints the token to the screen. I need to change this so that it saves to the database - I assume I should just create a column on my user's table and store it there?
I've tested the token and can access the API routes using Postman. However, because at the moment I'm creating web apps that all need to use this centralised user system, I'm not sure how I can use a login form to authorise users and allow them access to their dashboard.
If user's are logging into app1.com do I send a POST request to maindomain.com? Isn't that going to be a problem with CSRF? I've read the documentation but as this is my first venture into Oauth2 I am pretty confused.
If you want your login form to reside on app1.com, your only choice is Password Grant flow - app1.com will get user credentials and make a POST request to oauth/tokens on maindomain.com trying to get an access token. This POST request may happen in front-end or in back-end (more secure - client password will be hidden), that's up to you.
Otherwise, it sounds like your Authorization Code flow is already up and running. You could just keep redirecting users to maindomain.com (Facebook and most other OAuth2 providers choose this way), use the login form there, and then redirect back and fetch access token based on authorization code. Save that code in your app1.com database and allow users to access dashboard using that. When it expires - start the flow again.
Try watching this video by Taylor (the creator of laravel) to get going:
https://laracasts.com/series/whats-new-in-laravel-5-3/episodes/13
I created repos for both project and confirmed them working as they should:
API Server:
https://github.com/jeremykenedy/laravel-passport
API Consumer:
https://github.com/jeremykenedy/laravel-consumer
Try making protected API end-points in the routing file api.php and use token scopes if needed to further protect the API endpoints :)
I am developing a backend for mobile app. I have developed a user authentication module where, the app will be sending the username and password as basic auth and if the user is authenticated I will sent back a jwt token which can be used in the rest of the requests.
On the client side, once after a user is logged in, the app shows him a feeds screen which contains some data.
Now do I need to seperate these two APIs? Like once a user is logged in successfully, he will be sent back the jwt token and well some user details. Should I sent the data which is required for the dashboard screen as well as a response for login? In that the case the app will get datas in a single api request (login) and doest have to make another call to my API.
Is this a right approach?
Ideally it should be kept seperately but I think that depends. If making that single request is (and will ever be) the only thing the application does, I see no reason for making 2 requests. You can simplify things by making just 1 request.
But, if your application is going to be extended or if its already got other features i think it is best to keep them seperate. Since then you'll have more flexibility with your application.
Yes ,You should separate those two authentication and dashboard REST API as-
It could be possible that there should be more client app using your Rest API in future and they may not require dashboard data.However you can have mechanism to share user detail in authentication API itself as you are anyway authenticating user .However share access token in authentication api along with it's expiration timestamp .Some of Client app which are using your REST API might have use case of autologout from app based on accesstoken get expire.In such case expiration time would help.