How to best implement backend security?

[Jonathan Price]

The company I work for is building an application in which security is of the utmost importance.  We're really hoping to use Angular as the client-side application, and we're exploring how best to create our backend in ColdFusion (which we've used for a few years now).

I understand that only so much security can exist in the front-end of the app, and that the bulk of the work needs to happen on the server.  But I'm really unsure about how to move forward in that regard.  From what I've read, it sounds like we'll need some kind of Authentication Token to be created on login and stored on the backend.  This token should come along with every http request, and the server can then decide on the validity of the request.

Does this sound about right?  And if so, are there best practices for implementing it?

Also, any resources that might shed more light on the topic would be hugely appreciated.

Thanks,
Jonathan

[Eric Eslinger]

You should check out json web tokens - jwt.io; they're awfully helpful.

What I do (b/c I started this before I learned about JWT) is handle logins on the server side, and return a token value to the client. The client uses that token as a bearer token on all $http request by saying           $http.defaults.headers.common['Authorization'] = 'Bearer '+token

The token itself is just a base64'd random hex string that I store in redis as a key, with the value being the user's ID. So every request on the backend ends up hitting redis to make sure that the user is logged in to the right token. The nice thing is it makes it easy for me to impersonate a user for testing purposes (I can manually insert a token into redis), and I can revoke login tokens whenever I want. JWT is a bit more standard and relies on cryptographically signing the token but then storing state in the token itself, so you don't have to check redis, you just check the crypto signature of the token.

Either way, attaching a bearer auth token to every $http request isn't too hard, and then you just have to make sure you're on an HTTPS connection (tokens can get sniffed or MITM'd from regular http). It's marginally more secure than cookies- harder to CSRF or XSS the tokens.

Just remember that you can't trust the client. So any data users shouldn't see needs to be stopped on the serverside. Because users can and will hack URLs to see stuff they shouldn't see.

e

--
You received this message because you are subscribed to the Google Groups "AngularJS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to angular+u...@googlegroups.com.
To post to this group, send email to ang...@googlegroups.com.
Visit this group at http://groups.google.com/group/angular.
For more options, visit https://groups.google.com/d/optout.

[Puritan Paul]

Perfect, thanks for a pointing me in the right direction.  I’m not totally sure how this will play into the routing portion of the app yet, but I’ll burn that bridge when I get to it.  Thanks!

You received this message because you are subscribed to a topic in the Google Groups "AngularJS" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/angular/c6kSFMD2PWo/unsubscribe.
To unsubscribe from this group and all its topics, send an email to angular+u...@googlegroups.com.

[Puritan Paul]

So, this header:

$http.defaults.headers.common['Authorization'] = 'Bearer '+token

is the best place for the token?  As opposed to 'X-Access-Token’ or 'XSRF-TOKEN’ ?   I don’t really know anything about these headers and there purpose.

On Nov 21, 2014, at 2:02 PM, Eric Eslinger <eric.e...@gmail.com> wrote:

You received this message because you are subscribed to a topic in the Google Groups "AngularJS" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/angular/c6kSFMD2PWo/unsubscribe.
To unsubscribe from this group and all its topics, send an email to angular+u...@googlegroups.com.

[Eric Eslinger]

Yeah, that is more or less the standard. There's a number of server side libraries that handle bearer tokens, and that's where they do it. I use hapi.js as my back-end framework (it's a pretty darn good node.js framework for REST apis), and the Bell plugin for them does it really well. 

e

On Fri Nov 21 2014 at 8:58:22 PM Puritan Paul <purit...@gmail.com> wrote:

So, this header:

$http.defaults.headers.common['Authorization'] = 'Bearer '+token

is the best place for the token?  As opposed to 'X-Access-Token’ or 'XSRF-TOKEN’ ?   I don’t really know anything about these headers and there purpose.

On Nov 21, 2014, at 2:02 PM, Eric Eslinger <eric.e...@gmail.com> wrote:

You should check out json web tokens - jwt.io; they're awfully helpful.

What I do (b/c I started this before I learned about JWT) is handle logins on the server side, and return a token value to the client. The client uses that token as a bearer token on all $http request by saying           $http.defaults.headers.common['Authorization'] = 'Bearer '+token

The token itself is just a base64'd random hex string that I store in redis as a key, with the value being the user's ID. So every request on the backend ends up hitting redis to make sure that the user is logged in to the right token. The nice thing is it makes it easy for me to impersonate a user for testing purposes (I can manually insert a token into redis), and I can revoke login tokens whenever I want. JWT is a bit more standard and relies on cryptographically signing the token but then storing state in the token itself, so you don't have to check redis, you just check the crypto signature of the token.

Either way, attaching a bearer auth token to every $http request isn't too hard, and then you just have to make sure you're on an HTTPS connection (tokens can get sniffed or MITM'd from regular http). It's marginally more secure than cookies- harder to CSRF or XSS the tokens.

Just remember that you can't trust the client. So any data users shouldn't see needs to be stopped on the serverside. Because users can and will hack URLs to see stuff they shouldn't see.

e

On Fri Nov 21 2014 at 1:18:53 PM Jonathan Price <purit...@gmail.com> wrote:

The company I work for is building an application in which security is of the utmost importance.  We're really hoping to use Angular as the client-side application, and we're exploring how best to create our backend in ColdFusion (which we've used for a few years now).

I understand that only so much security can exist in the front-end of the app, and that the bulk of the work needs to happen on the server.  But I'm really unsure about how to move forward in that regard.  From what I've read, it sounds like we'll need some kind of Authentication Token to be created on login and stored on the backend.  This token should come along with every http request, and the server can then decide on the validity of the request.

Does this sound about right?  And if so, are there best practices for implementing it?

Also, any resources that might shed more light on the topic would be hugely appreciated.

Thanks,
Jonathan

--
You received this message because you are subscribed to the Google Groups "AngularJS" group.

To unsubscribe from this group and stop receiving emails from it, send an email to angular+unsubscribe@googlegroups.com.

To post to this group, send email to ang...@googlegroups.com.
Visit this group at http://groups.google.com/group/angular.
For more options, visit https://groups.google.com/d/optout.

--

You received this message because you are subscribed to a topic in the Google Groups "AngularJS" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/angular/c6kSFMD2PWo/unsubscribe.

To unsubscribe from this group and all its topics, send an email to angular+unsubscribe@googlegroups.com.

To post to this group, send email to ang...@googlegroups.com.
Visit this group at http://groups.google.com/group/angular.
For more options, visit https://groups.google.com/d/optout.

--

You received this message because you are subscribed to the Google Groups "AngularJS" group.

To unsubscribe from this group and stop receiving emails from it, send an email to angular+unsubscribe@googlegroups.com.