I have an Angular 10 Universal project that uses JWT retrieved from localhost in order to authenticate requests for private routes.
I currently use this project for the authentication process:
https://www.npmjs.com/package/#auth0/angular-jwt
The problem I believe I am facing with Angular Universal is that when rendering pages that require authentication my requests are unable to retrieve the JWT token from localStorage. Note, this is what I think the issue is because I get a 401 unauthorized on these requests and have done some reading.
Is there any way to authenticate these requests using the JWT token that is returned when a user logs in to the website?
Backend is .Net Core 2.1
Can you save JWT to cookies after receiving it? In that case JWT will be sent along with the request, so it can be processed on server side.
Also, i think it would be nice to set this cookie with secure flag, so it can't be accessed from js in case of xss vulnerability (so it cannot be sent to 3rd party service)
Related
When a user logs in, I store the login variable in redux but when we hit the api request then firstly react.js checks the authentication using redux if loggedin then the node.js checks the authentication and returns the api.
Isn't it unnecessary using authentication on both sides? Why can't I just use authentication on server side only?
Your thoughts please on what should I follow.
I think you need not to authenticate both side. You have to just send token in headers (authentication) of every API and create middleware for authenticate user for API in nodejs.
there are multiple ways to implement authentication in you're front end projects though the most common way to do this is by using JWT (json web tokens) however for using this type of authentication you need to implement OAuth, OpenID connect or similar authentication service on you're backend .
ps: I recommend storing you're login credentials in cookies
I've a backend RESTful API built in NodeJS and a front end application in React JS(NextJS), both hosted on AWS. The client and server communicates using JWT token.
I want to make sure both the client app and server side app are highly secured.
What i've done:
I'm using HTTPS for both client and server
Whitelist the client react app IP address so only the client react app can talk to the server app. This was done in AWS security group
Use cors in my server Node.JS application, to whitelist the client IP address again as an addition to No. 1
Use AWS WAF to secure the backend NodeJS application,
Use helmet in the NodeJS server backend API
Make sure the JWT token only last seven days, it'll be invalid and the user needs to login again to get a new token.
Answers i've looked at and used:
How to secure client app (react) and API communication
According to: RESTful Authentication i'm using Token in HTTP headers (e.g. OAuth 2.0 + JWT), this i sent for every client request
Using a refresh token: Refresh Token Jsonwebtoken
What i'm concerned about, and i need some help with:
1. Since the JWT token is how the server validates the client, is the JWT communication secured? Are there other steps i can take to improve the JWT security?
2. Is this application architecture secured enough?
3. Is there anything else i can do improve it's security, as i'm really concerned and want to make sure it's very secured.
4. Should i encrypt the JSON payload sent from the client to the server? because that's visible in any browser network tab under XHR, i'm sending username & password as payload for login.
I'm mostly concerned about security because i've integrated stripe payment in the application, and i'm also storing some sensitive data.
Any recommendation would be high appreciated, this is my first time deploying an production app.
As of what you have done the application must be pretty much secure.... except i would like to add a few things....
Make sure that the tokens have expiry and use refresh token to issue new tokens. The jwt stored at clients could be vulnerable for man in the middle attack. (For more performance use redis to store refresh tokens... look more on this)
If you are using https, the request will be only visible to the client's browser and not to any sniffers in the network (check on this whether ure able to see encrypted payload in sniffing tools like wireshark etc... to validate the https uve used). So its not necessary to go for any more encryption. That would decrease the performance of the api server.
I am working on deploying my Node.js app into production. We had been running into some CSRF issues but after looking deeper into the problem and learning more about CSRF attacks, I'm wondering if we even need to perform these checks.
Our API is whitelisted from our CSRF checks so our mobile apps that rely on the API can run properly (we're working on securing that currently). On the web frontend, we allow our users to register/log in and create/edit their data. We use Firebase's email/password authentication system to perform authentication (https://firebase.google.com/docs/auth/web/password-auth). As I understand it, this means we don't have to worry about CSRF attacks on registering and logging in because Firebase handles that. My question is: if we make sure our users are authenticated with Firebase on each Post route in our app, does that mean we don't have to worry about CSRF attacks?
CSRF becomes an issue when you are saving a session cookie. Firebase Auth currently persists the Auth State in web storage (localStorage/indexedDB) and are not transmitted along the requests. You are expected to run client side code to get the Firebase ID token and pass it along the request via header, or POST body, etc. On your backend, you would verify the ID token before serving restricted content or processing authenticated requests. This is why in its current form, CSRF is not a problem since Javascript is needed to get the ID token from local storage and local storage is single host origin making it not accessible from different origins.
If you plan to save the ID token in a cookie or set your own session cookie after Firebase Authentication, you should then look into guarding against CSRF attacks.
Is there any way to keep server side sessions in node js for requests coming through mobile applictions, Or it is in a way compulsory to use other methods like jwt?
As we do in Web applications, i.e Store the user information in the session on login and use the same information for later api calls.
Yes, there is and the simplest solutions is to use JWT, you can implement jwt authentication in you node.js server with any approach you want like: passport-jwt, express-jwt,... or even yourself with just jsonwebtoken npm package.
then for keeping mobile application authenticated with server, store the jwt token in mobile local storage and when app is opened just check the storage for if the token is exist or not and when there is jut add the token to the header and practically your mobile app keep a seesion open with server.
and for more information about jwt i ask a question about difference between session and cookie that might help you:
Authentication: JWT usage vs session
I'm working on an application using sails. web and mobile.
I want to use CSRF protection that sails provides when the app is visiting on the web. And if a request is send by the mobile app. send with the payload a jwt.
On the sails' documentation I found a property csrf.routesDisabled that disabled the CSRF for some routes. But that is not what I want. I'm trying to find a way to for example, check if the parameter jwt is send in the post request. And if the parameter was send then check and validate it. else, check for _csrf value of the form. Is this possible?
or the csrf protecction works before any information is send to the server?
my better choose is use jwt in the web app too?
any other good idea for solving this problem is welcome
thanks
Sounds like you've built the web app with SailsJS and you're trying to reuse the controller actions as REST endpoints for external applications.
Really what you should do, is decouple the data access from the front-end. Have an isolated REST API - using token authentication - which is used by both a web front-end (and any other applications).
For example, I'm currently working with a SailsJS REST API, used by an EmberJS front-end and an iOS app. Both front ends login using user credentials, in order to receive an authentication token. This token is then used for any future requests. A policy locks down all but the login authentication endpoint, to validate the token