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 <[email protected]> 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 <[email protected]> > 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 <[email protected]> > 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 [email protected]. >> To post to this group, send email to [email protected]. >> 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 > [email protected]. > > > To post to this group, send email to [email protected]. > 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 [email protected]. > To post to this group, send email to [email protected]. > 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/angular. For more options, visit https://groups.google.com/d/optout.
