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.
Related
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 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.
I am developing an Ionic App which consumes data from a Laravel 5 RESTful API. All the connections are protected (GET, POST, etc.) by username/pass and user roles, except the user creation.
My first doubt about security is to disallow connections from outside the App, avoiding thousand of user creations, overloading our server resources.
My idea is, when an user installs the app and opens it for the first time, to create a secret token which will be sent in every connection. Then check the device UUID and the secret token to ensure this is an authorized app.
What do you think of securing the connections this way? There is a better idea?
You need to look a JWT (Jot) JSON web tokens, they will solve the security issue. This can contain user id and other data like access level. Not things like security information or card information.
When a user authenticates Laravel sends them back a JWT which you store in local or session storage this replaces backend sessions.
It is generated by the backend using the parts that can be decrypted by the frontend and using a secret key to encryt the signature, if any of it is tampered with it will fail and deny access.
Every request angular will append the token to the header using a request interceptor and Laravel middleware will decrypt it and allow access to the route they need or return a error code '404' maybe.
If after install this authentication layer you can limit usage at user level on the backend.
But this should sort most of your issues, it a bit of a change in thinking but it does work and it solves a lot of sessions issues you get with ajax calls and it make load balancing easier because all server are looking for a token it can manage.
I was also encountering the same problems. But after search in google for a while I came to the conclusion that you can put up several walls against hacker, but for someone who is hell bend on hacking your app(ninja hacker) will find ways to use your app in malicious ways.
I also came across various ways you can protect your backend server(after google). These step generally make it difficult to use your app maliciously.
You can encrypt strings url using some algorithm and use encrypted string in program ie. https:\google.com\ is encrypted into something like \h09ae\hff00\hebab\h.... then in program String url ="\h09ae\hff00\hebab\h.." This way someone decompiling the app can't find your server backend url. In this case you need to decrypt the string url before you can use it.
Send sensitive data using HTTPS and inside the body of the request
You can verify if request is coming from the device by using google token. For this you will have to use Google API Console. Refer this link for proper android tutorial on this topic.
Lastly, sign key used when you create your apk is unique and ensure that your apk is not tampered with. So generate hash key of your sign key before it is upload to google play and save it in your server and programmatically get hash value of sign key and send it with very request to your backend.
Hope is helps you..
I am here with some general discussion very famous and interesting topic "Token Based Authentication".
I need my registered users to login with API. Scenario is quite simple, We want to pass our login details to Server. Server will check the credentials with database. If credentials are proper then Server will create "Session Id" and return back to user (client end). In subsequent requests user just need to pass that "Session Id" to authenticate and access protected data.
Plenty of people suggest about OAuth 2.0 and also some people suggest about Custom Logic. In custom logic they asked to be very sure about security. I read documentation of OAuth and it's good and descriptive. I'm also liking it to use. But wherever I search for OAuth authentication, they are giving example of third party login.
I had installed Php OAuth extension at my side for supporting this feature. In examples they asked to create Request Token first using "getRequestToken" function. Using that Request token they asked to call "getAccessToken" function to get "Access Token". Using that Access Token just need to call "fetch" to get protected data.
Now my questions are,
In my scenario, Do i need Request Token? Is that possible to get Access Token directly
What is OAuth Consumer Key and OAuth Consumer Secret key? Do I need such keys in my application? I believe it's used to allow third party applications only. In my case I'm the resource owner and i'm the consumer.
Do you guys have any example for me to study?
Do you know any well known framework for OAuth for PHP?
Is that need any additional database support except "user" table? For storing OAuth details?
Any additional documents to study for this would be highly appreciated.
I read different Grant Types in OAuth but confused how to use to achieve my approach.
Thanks in advance.
From what I read, you do not need OAuth at all. OAuth is need if there is a third party involved that needs access to your user resources.
As you mentioned, you just need a Login API something like https://myserver.com/signin?user=john.doe#gmail.com&password=12345
After successful login, the server generates a GUID and stores it against the user. You can call it sessionId/cookieId anything you like. Response could be something like '{user:john.doe#gmail.com; sessionId=KJN93EJMQ3WEC9E8RCQJRE8F9E}'
For subsequent calls, the sessionId can be passed in the header.
Server validates the session and lets the user in.
Addtional considerations:
I am assuming your server is HTTPS and hence the user/pwd on the URL are encrypted.
For security you might want to invalidate the sessionId have the sessionId renewed periodically.
Have a logout on which you clear the sessionId against the User.
I think it standard stuff if not the logging in happening via REST.
The requirement that I posted before to login with OAuth2.0.
Usually people assume that OAuth2.0 is only for fetching data by Third Party application from resource center behalf of Resource Owner. That approach is called Authorization Code.
OAuth2.0 has various "Authorization Grant". There are four types,
Authrozation Code
Implicit
Resource Owner Credentials (User Credentials)
Client Credentials
After research, I realize that "Resource Owner Credentials" is best suitable for me. I found one perfect library that helps you to understand background process internally. Here's the GitHub link to download.
Found two major issues here,
When I use my Access Token created by my Mozila in Chrome. Surprisingly, It's allowing me to access my private data from other browser.
I'm unsure but will this approach work same with AJAX type of calls (jQuery tool)
If anyone has idea then please share.
Thanks,
Sanjay
I'm currently building a web application which is an AngularJS frontend that communicates with a RESTful API built using Laravel. I'm making good progress, but finding it hard to get my head around how to handle user authentication.
I've been advised that I should be using OAuth for authentication, and I've decided to use it seen as it could be a learning experience for me as well. The package I'm using to handle this is oauth2-server-laravel.
The basic user story is that users can register their username/password combination for the application, and they then log into the application with that same username and password. They're only authenticated by their username and password, and not by any client secret. After login, they should be given an access token which will be send along with every future request to authenticate them on different API endpoints.
The OAuth2 library has a "password flow" grant type which seems to be what I need, however it also takes client_id and client_secret parameters, which I don't want. The request URI is something like this:
POST https://www.example.com/oauth/access_token?
grant_type=password&
client_id=the_client_id&
client_secret=the_client_secret&
username=the_username&
password=the_password&
scope=scope1,scope2&
state=123456789
But what I want is just:
POST https://www.example.com/oauth/access_token?
grant_type=password&
username=the_username&
password=the_password
How am I meant to provide a client ID and secret of a user that has yet to authenticate?
Is there a different grant I can be using, or is what I want to achieve just not suited for OAuth at all?
Take into account, that client id and client secret aren't parameters that you have to force your end-user to pass. They are static and defined in/for your client app (angular app in this case).
All you need to do is to create a record for your main app in oauth_clients table, and create a scope with full access in oauth_scopes table, and send this values when requesting token.
And that's all in fact.
Also, you may want to consider using implicit grant flow in case of building js-only application, because storing client secret and refresh token in a js app is insecure. Using implicit grant in a final product may look like login window on soundcloud and is more secure as the token is obtained server-side without exposing client secret.
Another way to go, if you still want to use password flow is creating a proxy for refreshing tokens. Proxy can hide your refresh token in encrypted http-only cookie, and your js-app don't ask your api for new token, but the proxy instead. Proxy reads refresh token from encrypted cookie, asks the api for new token and returns it. So the refresh token is never exposed. If you set token ttl for an hour let's say, then stealing a token would be quite "pointless*" in case of a normal application, and stealing refresh token would be "impossible*".
*Of course if someone really want he probably could hack it any way.
And yeah, i know this all looks a bit hacky - modal windows for logging in, proxy etc. But also searching on this topic i couldn't find any better and more elegant way of doing it. I think that's still a lack that all js-apps have to deal with if you want a token based authentication.
You are missing something with the OAuth specification. The client_id and client_secret are really important when asking for an access token when using the password method of OAuth v2. In fact, they are important for every method that gives you an access token. They identify the application or the server that has perform the request.
For example, let's say you have your API, 2 mobile applications and another server that do some tasks with your API. You will create 3 clients with their own client_id and client_secret. If your application has various access levels (they are called scopes in OAuth v2), the client_id corresponding to the other server will be able to call functions of your API that require the scope admin whereas your mobile application will only be able to call functions of your API that require the basic scope if you have defined scopes like this.
If your API grows up in the future, this is really essential. Another example, let's imagine you have given an API key (a pair client_id and client_secret) to one of your friend and he has build a nice mobile app with your API. If one day he starts doing naughty things with your API, you can't stop him very easily. Whereas you could have just removed his key pair if you had followed OAuth v2 principles.
OAuth v2 is not an easy thing to understand, take the time to read specifications and good tutorials before developing your API.
Some useful links :
The official RFC : https://www.rfc-editor.org/rfc/rfc6749
A tutorial on Tutsplus : http://code.tutsplus.com/articles/oauth-20-the-good-the-bad-the-ugly--net-33216
Just to add a bit to plunntic's excellent answer: remember "client" is not related to "user", so when I use a password flow I just define the client_id and client_secret as constants on the AngularJS app to tell the api backend: hey, this is the browser app that is being used to request a token.