Angular.js route authorization - javascript

I'm building a web/mobile app using Node.js(Express) server on the backend and Angular.js for the frontend. I'm using passport for sessions and I have some problems with a client side authorization validations.
On user login the server responses with a json cookie containing some session information like username and role. I want to make angular.js route authorization to limit the user access based on hit role. On every redirection I first check the cookie. If the cookie is there and the user's role matches the path's access requirement everything is ok and the redirection is done. If some request from the client side to the server side fails with a Not authorized response the session cookie is deleted and so on...
What is the problem... There are a lot of session validations on the server side but checking the cookie on the client side isn't very secure. Every one can see the cookie format (it's a simple json) and change it. For example everyone can change the role property of the cookie to 'admin' and only with cookie validation the client side will give access for example to the admin's panel view. Access only to the view! A further requests to the backend with this cookie will fail but it's not good to give them access to the views...
The server uses the SSL protocol but this encrypts only the communication, the stored cookie on the client side isn't encrypted.
I was thinking the sent cookie to be encrypted and the client side to decrypt it for authorization validation. But the user can open the clients js files and find out the decrypting key if it's stored in a plane text. If the server sends the key to the client side and the client side stores it in a variable the key will be not visible to the user but it will be lost on a page refresh. It will be not very smart to keep it in cookie :D
Of course the client side can send authorization request to the server for every authorization validation but this can be a lot of request.
Can you propose my some solutions?
Thank you very much and have a nice day :)

Related

What is the correct way to send a jwt token from server side to client side?

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.

Secure user token between SPA HTML5 app and web service?

Sorry if this has been asked a few times, but can't quite find out a solid response.
I want to secure the login procedure and session (kind of) between an HTML5 app and a PHP web service. I present the user with a login screen that uses HTTPS with the server, and then give the client a random GUID that is stored in a database with their time of login and last request time, and their actual user ID that I store for their row on a users table. So the GUID might be different every time but the user ID it maps to on login can only be seen server side.
I'm vary weary when it comes to authentication and never really dealt with a HTML5/JS app against a web service like this. I've usually developed ASP .NET sites and used sessions.
I've recently discovered JWT tokens which encrypts data stores in the token string that is contained on the client and passed to/from the server. Is this safer than what I'm doing? Should I be using JWT as opposed to this GUID mapping I have now?
What I'm aiming for is a session-less request to a web farm which could put you on to any specific web server, and the request is validated to see if that request has came from a valid logged in user.
Any advice would be welcome :).
Thanks.
Using a JWT token is totally safe provided you don't encode sensitive data in the token because the token can be decoded without the secret.
What you can do is to have two key pairs (private/public) RSA keys.
Private for encoding the token and sending it to the client on login success
the client saves the token to maybe a cookie, HTML5 localstorage e.t.c,
on every request, the client passes the token via the request header back to the web server, then the web server verifies the token with the public key. whilst decoding the token and getting the GUID from the token and can then proceed with the request.
This workflow can work across several server side languages as there are many JWT libraries for them.

Websocket in more pages

I create a simple login/password html5 application. Login/password I send via websocket to server to control and set in server side some permissions etc.
How can I connect to this socket in next pages and server can sending correct data which permissions available etc.
Or this login password have I sending always when I connect to socket in every page?
You can store token/session id in cookie.
On following navigation pages you can send that token to websocket to authenticate. Upon successful authentication you can response.
P.S. you need to create new websocket on every page load.
You can use regular web authentication using cookies.
WebSocket HTTP negotiation will carry cookies over. So you can return a cookie when the user connects with an generated UID if there is no any in the request, and then when the user authenticates, consider that UID as authenticated and associated with a User. Each time you get a connection with that UID you know it is that User.

What is the challenge/response method to securely authenticate with a Server without HTTPS (without sending out password)?

What is the challenge/response method to securely authenticate with a Server without HTTPS (without sending out password)?
I have an app (Javascript client) that connects over CORS (authenticate) to our backend which in turns will return a token containing the claim (JWT) over non-HTTPS. The REST is stateless so we do token-based and not have session at all.
When the client gets that token, (containing claim) it is added to the header for each request of the client and therefore the backend knows which User Id is doing that request and do the appropriate thing. So far this works for us. My concern is with the authentication process and with the security of each request.
To authenticate the clients sends out email and hashed password pair, however I want to know if there's a more secure way even without using HTTPS for now. I've read to not send the password but do a challenge/response, but what is the implementation of that idea?
And last question would be, even if we get around with the authentication process securely, how about on each request which contains the token with claim can it be secured also?
There is no possible way to do this securely without HTTPS. For your server to authenticate users, you need some kind of token (cookie, adding to requests like you have, etc.) However, the problem is that, without https, an eavesdropper can add javascript to your page. They can then capture the token and use it themself (stealing all the user's data), or modify it. If you want your product to be in any way secure, you need HTTPS.
Edit: I guess you could store some information about the device sending the request (user agent and such), and only allow the token to be used on that device. However, an attacker could just fake the user agent when they reuse the token, so this wouldn't be too hard to bypass.
Challenge response is a mechanism to send passwords in non-clear way.
1°/ client and server must share a cyphering key : best is to manually add certificate on client but could be a little bit heavy. Another solution is to store the key only one time into localStorage.
2°/ client requests a challenge to server : this is a "phrase" generated by server
3°/ client concats its password with this "passphrase", ciphers and send response to server : Challenge => Response
4°/ server decrypt message, search and remove its passphrase to get password.

How to save username and password in client side templating application

I am writing a web application using client side templating. This application needs to interact with a REST Server which supports Basic Http authentication (using ssl). So, with every request that needs to be authorized, username and password are passed in Request header.
My question is where and how to store username and password so that they can be accessed client-side by javascript code.
I wouldn't store usernames and passwords on the user's system. This is a security problem.
Instead, your REST login service should send a session cookie back that includes an encrypted authorization key. That cookie will then get passed back up upon further REST calls and your REST service backend can read the cookie to validate that the user has a valid authorization token.
If you don't want to use the cookie mechanism because you have to use a different header, still consider using the auth token method and storing the auth token locally (using cookies or local storage). If you don't have control of the backend at all, and you have to pass username/password up, then I think you are stuck. Saving the password on the client's machine (in cookies or local storage or whatever) is a bad idea because it can be read in plain text. Any encryption method you use can be easily reverse engineered.

Categories