So if I use the node he client how is auth information being passed around ?
In the photo frame example it checks form data using the express body parser for a user and is authenticated function call.
But then it also calls api functions and makes requests outside the browser.
Just curious what the process is storing and where and how it’s being passed around.
Obviously the application tells Google what it is with some use of the client ids but is there a token the application has access to as well once OAuth is finished identifying the specific user account and where is that ? And how does the connecting browser keep this between server calls ? The response headers seem empty of anything of that nature. Thanks in advance.
Related
I'm working on express server application and there are bunch of api endpoints that I configured. Almost all create and update requests, I need to store requested user's userId in order to keep log. I created a middleware function that verify user JWT access token and retrieve userId from access token payload. In my current situation, I add user info as req.body.loggedUser in req body. I think this is not a good thing to do. I do it like,
req.body.loggedUser = accessTokenPayload.user[0];
This works fine in every POST request. But I need to do it in right way. And also this method cannot use in GET requests. If nodejs can keep temporary variable until a request done its process I can keep log on GET requests also. So all I need to do is keep user info as temporary data until request process done. How I can do it.
Just add it to the req variable:
req.loggedUser = accessTokenPayload.user[0]
This works in GET requests as well
I'm working on an implementation of the Facebook api and I'm to the point that i can fetch a users pages and would now like to display these to the user so they can select where to send the post. These page objects have an access token on them to verify requests with Facebook and intuition tells me you wouldn't want to send these through to the ui then back again. I could just make 2 calls when sending and receiving, filter the results to remove the access tokens, then when receiving a request make another call to the api and filter the page results by id.
I'm curious though if theres a way to get around making 2 api requests and reduce overall requests to the api and keep the usage down.
You could just store the page tokens in the session, when you get the list of pages - then you don’t need to make a second API request after the user made their choice.
(Session data is tied to a specific client, and never leaves the server. Only thge session ID is passed between client and server.)
In Vue, I understand that any Javascript included in the Vue files will be exposed to the browser (The User-agent in OAuth model). I want to make an API call to an API protected using OAuth 2 and have the data returned from the API call then displayed in the Vue app. Using OAuth, I need to use an Access token only known to the client server (node/express server) and I do not want to reveal the access token to the browser (user-agent).
I tried to see if I could do it using vue-axios, but that forces me to add the auth-token to the logic within vue, which means the browser can access the access token, which seems really unsecure.
So, I thought that I could make the API call on the node/express server that hosts the Vue application. Then, have the data included in the Vue app and send it to the user's browser with the data. The Vue app would then be rendered as normal. That would keep Auth Token hidden from the user's browser. However, I got stuck trying to include JSON data extracted from the api using Express in the Vue app.
How can I insert data into Vue using express, without putting code from the API call into vue?
Note: I'm new to Vue, so if anyone thinks that there is better way to do this securely, I'm open to suggestions.
It's possible you're trying to over-think this. You're not going to out-think the designers of OAuth. Consumers of apis need access tokens. Your OAuth access token is secure, in the sense that it can't be modified to get extra rights, and it should be short-lived, requiring regular re-authentication. You security lies in the fact that even if your user recovers the token, it won't let him do anything you're not happy for him to do anyway.
I'm currently sending the client an empty html document with a few scripts included that set up my single page application with react-redux. After everything is set up I'm fetching the dynamic data using AJAX and determine if the user is logged in or not. If the user is not logged in, he will see the products available only for users that are not authenticated and conversely.
Even though I am a noob, this seems extremly primitive to me and I don't know how I can do this better.
So what is the best way to handle authentication in react-redux applications?
Thanks a lot for helping.
There's a few options:
Passport which you can install through npm and it has a variety of strategies you can authenticate through such as Auth0 Link here
Firebase - a solution that google has that can be used as a drop-in authentication module. Link here
Meteor framework - I believe this framework has multi user authentication. Link here
First, for authentification you need to have a token or session id on the client side. So, there should be next steps:
After login, you receive token|session_id from backend and put it to the store and also to the localstorage not to lose it after page reload.
While initializing your app, get the token from localstorage and put it to the store every time.
When you do request for products list, add the token to ajax request (usually in headers).
Based on token, back-end application should returns another list of products.
It is a regular logic for such situations and of course it requires work on back-end side as well.
I am developing an express app which serves as a REST api with web client and may be future mobile clients. I am using a Oauth 2.0 token authentication for both clients. This gives a good deal of security against CSRF. I want to know How to provide security against XSS.
*I made the tokens validity period very less, requiring the client to request with refresh_tokens and other client details for access_tokens. This makes it a bit safe but not entirely*.
I am concerned with the with client_id and client_secret being stolen since its present in the front-end javascript code and it being used by other client to validate. I am thinking of using a JWT for the client authentication, will this be helpful?
Data Sanitisation is another which I am confused about. There are modules like validator, express-validator which give regex validation. According to this blog post JSON Schema validations are fast. In the REST Api JSON will used for data exchange so I was wandering why can't I use modules like tv4 or any other JSON Schema validators for data validations?? I am not asking for suggestions to use what, I just want to know the basic difference in the kind of validations each provide and specially from a point of view of XSS protection and sanitisation.
So you have three separate questions here:
1) How to protect against XSS: As long as you use JSON to share data between the client & server and use standard libraries/methods for encoding/decoding JSON, you are mostly protected. After this, you only need to worry about DOM Based XSS, which is harder to be protected. But basically you need to be careful for not using any user supplied input that can be interpreted as anything other than "string" you intended. (please visit https://www.owasp.org/index.php/DOM_Based_XSS for more information)
2) client_id and client_secret being stolen: This does not seem to be possible in the way you require. In your scenario (where you distribute clientid&secret in javascript code) there is no way on server side to know whether the request is coming from your client or a fake one.
3) Data Sanitisation: I see two levels of sanitisation in the libraries you & blogpost mentioned. validator or express-validator is mostly used to validate individual data fields. Whereas others can validate a JSON object structure in addition to what "validator" does. If you require all exchanged data is in JSON format (as suggested for XSS protection as well) then you can use json object validators like tv4. (the only drawback of tv4 seems to be allowing latest json spec, which should not be a problem for you)
BTW: It would be easier if you specified your client application is purely client-side javascript (angularjs). I could not understand your question until I found this info in comments.
I have developed Restful Authentication System same as your case with NodeJS, MongoDB, ExpressJS in order to provide flexible authentication system for multiple clients like web, mobile. Let me summarize you the important points.
I have used html5 localstorage to keep user token after first time login by using login form. When user click login button, username and password sent to server and validated. After successfull validation, unique access token sent to client and stroed in local sotrage. If you have vulnerability on your client application, anyone can get your access token and make request by using your token. In order to prevent this, you need to use ssl connection for your app. This problem does not exists only restful auth systems, this can be happen in server side session storage. Let me explain this. I am using PHP for session. When user logs in, user session saved in to temp file on server and that session id sent to client browser. Somehow, if I can get that id, I can make request with header that contains someone's session id. When you compare, restful auth seems more flexible to me. I suggest you to ;
Use SSL connection prevent your access_token from to be stolen
Generate access token with powerfull encryption methods(SHA-256)
Small expire time for access_token the better
Implement a middleware for token validation for backend service usage. I mean make your requests like;
/use/update/{userid}
with custom headers contains your user token.
Design 5 attempt failed system for your backend. If user cannot success at 5 time try, this means someone tries to send random tokens in order to get in to system. Detect and block that IP
You can also deny requests other than browser clients.
Those are the informations that I have learnt while implementing the project.