I have a React app with backend API written in Express (all /api calls are proxied there).
Upon successful user authentication, I will be generating a session ID and storing it somewhere on the client side so that I can later authorise requests to the API.
What is the best practice of implementing this architecture on the Express side? Shall I just send the session ID along with the body of each API request and then precede all backend calls with an authorisation mechanism? Or is there some better/easier way of doing this?
My intuition would be to take two steps.
On the client, set up your HTTP client to pass the sessionID as a header. You can set custom headers using an HTTP client like axios or, in ES6, fetch, and apply those headers to every request send to your Express API.
Set up a middleware function on your app that will run on every request received by the server. Express has an easy way to do this using app.all("*", yourAuthFunction). You can also take a look at app.use for applying a middleware to more specific routes. This will ensure that your sessionID gets verified on the server before any data is sent in response to the client. Of course, you'll have to write the auth function to work how you'd like.
Good luck!
When the user successfully authenticated (it should auth' anytime the page loads), a response should be sent to it (contains the session token).
Every other request should be authenticated with the session token that received on the authentication response.
You can store this token value into hidden input <input name="session" type="hidden" />
Related
I am building a simple app where users can read blogs written by authors. These blogs are fetched from an express backend that implements HMAC authentication. Every client app gets an appID and appSecret. Using this secret, the client creates a signature for every request and sends it in the Auth header.
Now, I am trying to figure out what is the correct method to add this Auth header with every request whether server-side or client-side. This works when I do fetch client-side in onMount, but the Auth header is missing for requests that originate from the load method in SSR.
Is this related to the below issue?
https://github.com/sveltejs/kit/issues/696
If yes, is there a workaround? Because this is a blocker for me.
All my load methods route requests through a common api.js module. I have tried modifying the header in api.js, in handle hooks but no success.
Long winded but I'm using Googles Youtube v3 Data API node.js package to sign in users and view playlists and such. Currently when a user successfully logs in with googles Oauth redirect flow a route server side is called which passes in a code by url query parameters. I'm able to parse that out, generate a token with my oauth2Client and then create a signed jwt. Right now I redirect the user to a url that has the signed jwt as a url query parameter which is then parsed out browser side and stored as a token in the local storage, this is my first time using anything related to jwts and want to be certain that I am doing things in a secure way. Being such I'm not entirely sure that how I am sending the token server side to client side is the proper way and not quite sure where to start looking.
You can pass in response like res.cookie(key, value)
There are multiple way to pass token from server side to client side
1) you can pass token in your response
2) you can pass token in response header
It is not the right way. If the server is responding to an XHR request (coming from javascript), then the server can send the JWT in the body of the response. If the server is responding a regular browser request (GET or POST, but not handled by javascript), then it's easier to just put the JWT in a cookie.
There is Spring MVC application - the server produces HTML, the client is not SPA (i.e. this is not about API in any form).
During authentication JWT token is generated and returned to the client. During authorization the server verifies JWT token.
How to store JWT token on client side and pass it via all further requests to the server? Remember this is Spring MVC application and not SPA.
I tried to google for any examples but the only findings relate to REST authentication, that doesn't relate to this case at all.
In worst case we can perform authentication from JavaScript and store JWT token in cache/cookie. But maybe Spring MVC supports this out of the box and we need just to set some checkbox in configuration :-)
For non-SPAs, the usual approach is to store the authentication token in the server session. When the client makes a request, the appropriate session is retrieved via the JSESSIONID cookie (or the JSESSIONID is added to the URL if cookies are disabled).
I'm not sure why you can't use the approach above, but if you want to store the JWT on the client, a common approach is:
store the token in the browser's local or session storage when it's generated, e.g. window.sessionStorage.authToken = 'token_value';
add the token to each subsequent request by setting the Authorization HTTP header to the value of the token
when the user logs out, delete the token from browser storage
I can use "Set-Cookie" header with JWT token from server side. The client will interpret this header as setting a cookie automatically. In this case passing the token to every requests will be done without additional steps from client side.
Some details are described here https://stormpath.com/blog/where-to-store-your-jwts-cookies-vs-html5-web-storage
I will use this as an accepted answer until a better option provided.
So I'm unsure of the practicalities of authentication on a SPA, as I try to get used to my new stack of choice.
I will be serving a Node/Express app, with all API routes on /api, and the frontend served on the root / (all routes will serve index.html, then the client-side routing will take care of the rest. So I have the backend authentication set up with the Passport library, which works well. But how does one keep the server and client sessions in sync? As well as taking care of security.
If I make a POST request to /api/login with credentials, what do I return in the response to the client? And where is the session set?
My frontend is Vue, so I assumed I would just pass the user data (if credentials are correct) to the instance and have a user object. But I'm guessing I need to store a token of some sort? (jwt?)
If someone could clear up how this client-server architecture works, that would be great.
Cheers.
Whenever user logs in with credentials you can send a JWT Auth Token and then store the token as Cookie/Local Storage.
Then send the token as Authentication Token in each request as Request Header/Data to validate the user.
Link: Here is a tutorial with NodeJS
I've been looking around for an answer to this question, but it looks like that nobody does this. Imagine you are designing a javascript REST client, and you want to create a login page. Surely, after the login you will be authenticated.
So the following requests to the REST API will depend on your current user id, which should be stored on the client side following the RESTful way.
My question is how to store this "session" information using Javascript. I've looked into cookies, but it seems to me too much plain text for one to trust. Also using cookies one could store there an session id that maps to the user information on the server, but this violates the Stateless concept from REST.
Which the best approach to solve this problem?
We are also building similar kind of architecture where RESTful API will be accessed by a javascript client.
We will authenticate client with client credentials and generate an authentication token and that will be sent to client. Client will store it in cookie or in local data store. Further requests to API from this client will be sent using HTTP authorization header and including that token in the header. We will authorize the request at API end for the given token and request will be served once it is authenticated.
Until n unless you don't access cookie information on server side I don't think this will violate stateless principle of REST as we are not maintaining any state of the client on server (we are but not binding it to any server). Regarding the authentication process using token, I don't think we are binding the server and client here, because we have multiple servers and using load balancer and still this request may be served by any server (similar to Google api).
Note: We are doing this using HTTPS protocol so we are sure that all this communication is secured.