Develop Reference

Is that a secure way? Redux React Authentication

I‘m developing an adminpage with login functionality using Node.js, react and Redux.
For the login I used jwt. My question is, is it safe to use this? Because, i set Provider with the store around my App. And Inside i check if the user.isauthenticated() then adminpage Else loginpage.
What worries me is the store. It is the same store in the loginpage and in the adminpage. So I have access from the login page to the store which is connected to the adminpage.
Would not it be safer to have two separate stores?

Nothing on the front end is “safe”. The real question is how you handle authentication/authorization in your backend. JWT is definitely a secure method for authentication, but keep in mind that the payload can be decoded by anyone, so any information stored in a JWT is visible to anyone who can access the token.
The safety consideration is this: could a user authenticate using your front end service, then use that token to access information from your backend that does not in some way belong to them? If you’ve built your backend properly, then your front end stores won’t be able to leak any information, because they won’t be able to obtain any information the user wasn’t already authorized to view/edit.
One scenario to keep in mind with front end security:
A user logs in, and proprietary data is stored by your front end app (whether redux/localstorage/etc). When that user logs out, if that data remains in the store, could another user log in and then view it somehow? Hopefully not. Your logout methods should remove any sensitive data from that frontend app, so any future user won’t have access to it.
I hope that helps. I might not have addressed redux directly, but that is because security is primarily a backend concern. Redux shouldn’t be relied upon to keep data safe, unless it is deleting stuff permanently from areas that unauthorized users could access later.

Authenticating with PKI in Angular

I'm wrestling with trying to authenticate in an AngularJS application using PKI. All of the questions and examples I've seen show authentication using a login/password instead. However, I am running on an intranet, where we use PKI keys consistently. I've read the various suggestions online, but none seem to discuss my particular architecture.
The Angular side contains multiple pages/controllers, and I have no way of controlling which page the user visits first. I need the authorization information on each page.
The application is set up with a NodeJS REST service to get the user's authorizations and other information based on the user's public key (passed in thru the certs). Since the NodeJS service must contact external servers, I want to only invoke it only once, and retain an authorizedUser object (probably in rootScope?)
I've looked at creating services, providers, etc. But none seem to fit this challenge. To summarize:
Authorization using PKI certs, not login/password
Certs used to reach NodeJS REST service, but must only be invoked once
Multiple Angular controllers/pages need authorization information
What would be the best approach here?

OK - I figured it out. My approach was to put the webservice call to the NodeJS backend in the module.run(), and set the $rootScope within the $http.get().success() block. The NodeJS backend gets the certs from the webservice call, and does the lookups it needs to do.
I'm not sure if that's the best approach, but it works for now.

How to achieve a Safe (!) authentication system in an angularjs app?

I'm new with angularjs...
I read the docs, and completed the tutorial; i also tried something else by myself, and things start to make sense to me.
Now i wonder how to make a safe authentication system.
The easy part: no code, i will describe operations my code execute:
I've a classic form: username, and password text input.
The user fills the form, and press ENTER.
An ajax request starts, and the response is a JSON telling me
something like "ok i know you" or "i don't know who you are".
What i need now is to mantain the logged status of the visitor (or not logged) between the different views of my application.
I read on the internet that, to achieve this objective, someone sets a variable ($scope.isLogged = true), someone else uses cookies; but javascript variables, and cookies can be easily edited using firebug, or similiar development tools.
... and finally the question:
So, have you some suggestion to achieve a safe authentication system in an angularjs app?

You cannot authorize anything in angularjs, because the user has full controll of the execution environment (namely, the browser). Each check, case, if - anything you can think of - can be tampered with. There are javascript libraries that use asymmetric keys to perform local encryption to store local data somewhat safely, but they are not what you are looking for, really.
You can, and you should, authorize things on the server - the standard way you would do it in an ordinary application - using session; no special code is necessary, ajax calls use ordinary session cookies. Application does not need to know whether it's authenticated or not. It only needs to check what server thinks.
From the perspective of your angularjs application, being "logged in" or "logged out" is merely a gui hint for the user.

Probably you found a solution, but currently I made up an authenticaiton scheme I'm implementing in my Angular App.
On .run the app is registered with an ActiveSession set to false.
It then checks if the browser has a cookie with a token and a userId.
If YES, check token+userId on server and updates the token on both server and local (token it's a server generated key unique for each user)
If NO shows login form, check credentials and again if they are valid does a server request t get a new token and saves is locally.
The token is used to make a persistent login (remember me for 3 weeks) or when user refreshes the browser page.
Thank you

I asked this question three months ago.
I would like to share what has become my favourite approach when I've to deal with user authentication in a web app built over AngularJS.
Of course fdreger's answer is still a great answer!
You cannot authorize anything in angularjs, because the user has full
controll of the execution environment (namely, the browser).
From the perspective of your angularjs application, being "logged in"
or "logged out" is merely a gui hint for the user.
So, briefly my approach consists in:
1) Bind to each route additional information about the route itself.
$routeProvider.when('/login', {
templateUrl: 'partials/login.html', controller: 'loginCtrl', isFree: true
});
2) Use a service to mantain the data about each user, and their authentication status.
services.factory('User', [function() {
return {
isLogged: false,
username: ''
};
}]);
3) Everytime the user try to access a new route, check if they have the grant to access.
$root.$on('$routeChangeStart', function(event, currRoute, prevRoute){
// prevRoute.isFree tell me if this route is available for all the users, or only for registered user.
// User.isLogged tell me if the user is logged
})
I also wrote about this approach (more in detail) on my blog, users authentication with angularjs.

First of all: Client-side data can always be manipulated or tampered with.
As long as valid session IDs aren't easily guessable and measures like associating session tokens with the client's IP there is no big deal about it.
You could, in theory, also encrypt the cookie, as long as you do so on the server side.
For details on how to encrypt your cookies, see the docs of your server-side (e.g http://expressjs.com/api.html#res.cookie for Express.js)

You need to learn about the server side / database end of it.
User logins need to be stored somewhere - 99.9% of the time this is in a server side database.
Ideally for a really secure system you want a backend (server side) membership system that stores the session in a database table that is related to the member table that holds the encrypted password, but also provides a RESTful interface where you can build your api calls to.
One Script that I've used successfully a lot has been Amember https://www.amember.com/. It's a really cost effective way to go although there are a lot of other script out there, I've had a lot of success with this one.. It's also PHP so you can build your build out an API for your angular http calls really easily.
All of these javascript frameworks are great but the effect is that now too many are focusing too much on the front end of things - learn the database / backend as well! :-)

Web site using backbone for frontend and nodejs for backend

I'm developing a new web site that will be a single paged app with some dialog/modal windows. I want to use backbone for frontend. This will call backend using ajax/websockets
and render the resulting json using templates.
As a backend I'll use nodejs express app, that will return the json needed for client, it'll be some kind of api. This will not use server side views.
Client will use facebook, twitter, etc. for authentication and maybe custom registration form.
Client static resources, such as css, js, and html files will be handled by nginx (CDN later).
Questions that I have now:
How can I determine that a given user has the right to do some action in api(i.e. delete a building, create new building)? This is authorization question, I thought of giving user a role when they login and based on it determine their rights. Will this work?
Similar to the above question, will this role based security be enough to secure the api? Or I need to add something like tokens or request signing?
Is this architecture acceptable or I'm over engineering and complicating it?

Passport is an option for the authentication piece of the puzzle. I'm the developer, so feel free to ask me any questions if you use it.

I thought of giving user a role when they login and based on it determine their rights. Will this work?
Yes this will work. You can check for a certain role on the user after it's been fetched from the server. You can then display different UI elements depending on this role.
Will this role based security be enough to secure the api? Or I need to add something like tokens or request signing?
It wont be enough. Anyone could hop into the console and set something like user.admin = true. In your API you'll need to validate a user token from the request, making sure that the related user has the appropriate permissions.
Is this architecture acceptable or I'm over engineering and complicating it?
At the least you should have an API validation layer. That would make a decent enough start, and wouldn't be over-engineering.

For the authentication part of your question i would use everyauth which is an authentication middleware for connect/express. It supports almost every oauth-social-network-thingie.
For role management you could give node-roles a try. I didn't use it myself but it should help you out, because it checks the role on the server side. Of course that is only useful if your API is implemented in node.js. If that's not the case, you have to "proxy" the API calls over your node.js app.
I hope I could help you! :)

Where is best place to store authorization data when I use Backbone and AMD modules?

I create js app with Backbone and RequireJS for registred or non registred users. To retrive data from database I use simple JSON web service and of course some of methods are not avaiable for quest. Problem is that I don't know where or how I should store auth data retrive from server without reloading it in every view. Should I use cookies ?

I guess it depends on your authentication, authorization methods as well as the kind of security you need to consider for your users. If you're trying to be RESTful, you can't have sessions to save state (at least server-side). You could, but it wouldn't be RESTful due to saving of state on the server, if that matters to you. I've heard that it is okay to save state client-side but from what I've read, I'm not sure how the community feels about certain implementations that take this approach. (Like cookies, I'll revisit this later.)
Say you have someone login with username and password. You can hold that information in your Backbone app, maybe you have a model called AUTH that does this. Each time you make a request to the server you'd send that data each trip at which point the server authenticates and gives or rejects access to given resources. If you use Basic Auth this information would be in the header I think. Using SSL mitigates some of the major security concerns surrounding the sending of this information over the wire and for the rest of the discussion let's assume this is what we are using.
The other way that you could do this is to use encrypted cookie, encrypted cookie sessions. This is what I do with my current application. Honestly, I don't know if this is considered a violation of RESTful principles or not. The general chatter on the web seems to be a lot of "cookies bad, sessions bad" with some people saying, "get real." Using cookies would expose you to cookie hijacking if someone had access to the users computer, but depending on your application and the security needs it might not be an unreasonable option. It works for me and if it isn't RESTful, I like to call it RESTLike.
To close I'll just describe my setup. It would be nice to get your thoughts as well as the Stack's opinions on this also.
Basically I have a setup where when someone goes to the main page, the server checks for the encrypted cookie session. If the cookie session is invalid or non-existent, it gives the user the regular page with a chance to login. When they login, I send that information over POST so it's in the body of the request rather than the URI. (This is technically a violation of the REST HTTP verb concept since you use POST to save a resource.) When that information is processed, check the username, pass hash created by a unique salt, then the server creates an encrypted session cookie and passes it back to the user. Now, each time my user hits a route that requires authentication, the server checks the cookie to make sure it is still valid (time limit, user information, etc.) and if so - allows access. If not, it destroys the cookie information and sends back an appropriate status code. The backbone app reacts to this by resetting any view and data that shouldn't be in the hands of an unauthenticated user and shows them the login screen.
Hope this gives you an idea. This is the answer to how I do it, but if someone has criticisms or better ideas I'd be happy to upvote them instead.