I'm working with AngularJS and Parse (through the REST API). I am making a SPA and I have the following problem, all variables are erase when the browser refreshes the page. This means the user's session is closed. I thought of storing the session Token in a cookie to avoid this but If someone is able of retrieve this value, he or she could access all the users information.
What is the most secure way of archiving user's session persistence?
Thanks you all very much
Use sessionStorage. It will not be erased upon refresh.
Related
Maybe it's a silly question but I'm a bit confused about this.
I want to check whether a user is logged in or not but I don't want to use localStorage to save my JWT token. I know that I can easily save it in localStorage and check from there but for my application, I'm sending the JWT token through an HTTP-only cookie from the backend and from the frontend with every request I'm sending this.
So I'm confused if it is in an HTTP-only cookie I can't retrieve this through my script then how can I check the logged-in status except for local storage.
After googling sometimes I got one answer is using the redux-persist library to persist the application state but still under the hood it's doing the same job creating a copy of my state and saving it in local again which I don't want.
Anything else I can do about it or I have to use local storage ( maybe instead of saving the token I can save the user id or some other key: value pair)
I'm working on a e-commerce using next.js and sylius API and the API admin routes are secured using JWT. So in order to fetch products (for example), i need to login to the API, get the token and then fetch the products using the token. The most common method to be able to send the token on every new requests to the API is to store it in a HTTP-only cookie.
As the pages are generated statically, i feel i don't need (and want) to expose the API token to the client. So i'm wondering the best way to store the token ?
Here the different options i have in mind right now:
store the token as a http only cookie and use it server side (with a proxy using next js API pages) in order to call the sylius API. Like i said, i'm not confortable to store the API token into the client, it seems risky to me, as it will be exposed to everyone, and with that token you can access the admin API.
configure the API in order to prevent the token from expiring, and store it in the next js app as an environnement variable (.env.local), so that it's not exposed to the client and can be used for fetching the api when generating static pages. The official ecommerce theme of Next.Js seems to use that method (https://github.com/vercel/commerce/blob/f770ad7a91059a2ecfbb9de1bac111dfe7016124/framework/bigcommerce/api/index.ts#L82)
store the token somewhere in the next js structure but not as an environnement variable (maybe a config file?), so that it can be replaced if necessary (if the token expires etc).
get the token and store it in the react state as is it will be used once only for generating all static pages. On each build the token will be asked again by the API and then used for fetching the API for exporting the static pages with the content. It don't need to be saved more time than the building step.
For me the last option seems better but i feel i'm missing something there, i'm kinda new to next, so i'm not sure exactly if its a good solution.
Thanks :)
I get a great answer from a reddit user ("supermaguireray"), so i post it as an answer here:
"First of all, in any session management mechanism the correct information needs to live on the correct domains, what I mean is that your client can only have access to a identification information, but never to data used in the server, these can be applied to a server-side session, when a ID for the user data stored on the server is sent to the client (preferably encrypted), or in a JWT where a encrypted string is sent to the client (identification), and decrypted on the server (Data).
With that said, the only reason you should send the API token to the client is if you need to fetch data directly from a browser. Storing as a httpOnly cookie is the most secure way.
In case you only need the cookie fetch data to the next backend, to render your SSG or ISR pages, there is no need to send a cookie to the client. Just store the token in your server. I would store it as env variable. Use next.config.js->runtime-configuration.
Or, you can keep a expiration date for the token, and store the credentials, maybe even in a DynamoDB or FaunaDB app."
I am new to the Single Page Application. One big question for me is how to make my application secured. I am using React in the front-end and express + mongodb in the back-end.
I old web site, we use session to do the authorization. If session is timeout, we can let the user redirect to the login page. And if a user is keep do some actions on our website, his session will never expired.
But now, I am using JWT to do the authorization. A token may expired in 1 minuet, after that, the user have to login again.
For my understanding, one way is 're-send a token on every request/response, then each request/response will have a new token'. But I think this is not the correct way of how to use JWT.
So my questions are:
What is the correct way to avoid the user login again if he still work on our web app?
Do we need to store the token in the database (mongodb)?
If I store the token in localStorage, everyone can borrow it from the browser and copy the token into their client. How to avoid it?
I fetch the API tokens for the current user when he signs in.
This token needs to be persistent throughout the entire session.
I started by updating the default headers after the token was generated, but that update disappears when refreshing the page.
$http.defaults.headers.common.Authorization = "Bearer #{token}"
I tried to store it using $cookieStore.put('API-TOKEN', token), but that didn't work as it was saved with the /user path. Making it only available from the /user scope.
Storing it in a Session fabricator also failed as that where emptied on every page refresh.
My next attempt will be to store it using sessionStorage. Perhaps with the help from http://ngmodules.org/modules/ngStorage .
Which method is the preferred way?
Cheers,
Martin
I'm building an AngularJS application that interacts with an API that uses authentication tokens to authenticate users. Everything seems to be working fine, but I'm struggling with a way to properly persist the authentication token between requests.
At the moment, when a user logs in with correct credentials an authToken is returned, and I'm setting that on $rootScope.authToken. I'm also sending that auth token for future requests, but if I do a hard reload reload the webpage with F5 $rootScope gets cleared and I have to authenticate again.
I'm aware I can store the authToken in a cookie, but would that be the most secure way? Am I better off using local storage to store the token? If local storage is used, would that not get cleared when the user restarts their browser? I'd ideally like the login to persist for a few days.
Firstly, I'm not sure what the format of your authToken is but localStorage should not be used for any sensitive data. Using localStorage works great (and survives browser restarts) as long as your authToken is relatively tamper-proof either through some form of encryption or nonce.
Essentially, you should be careful that since the value is "visible" to all client-side users it should be assumed to be possible to modify or increment.
Have you thought about revocation of login sessions? For example, if you want to log out all active sessions of your application, how would you do it? Since the authToken is stored client-side, you may need to add a timestamp (or some other unique value) to it that can be checked server-side.