0

I am creating an Angular application, and I am having trouble wrapping my head around the proper way to ensure my application and its users is secure.

I've been reading around many stack discussions, but I believe I am missing some core understanding of what is happening, please correct any errors you see written below.

So far I have a Sinatra server with many (currently mostly hypothetical) resource routes. A user can create an account using an email address and password that is stored in a database after being hashed with BCrypt. When a user logs in, the record is retrieved from the database by email and the password checked for authentication. It is from this point I am not sure how to proceed.

Prior to this I have simply set a session variable and had the server check that the variable exists in order to correctly route logged in users. Now my application is (currently) a single HTML page that uses Angular and ui-router to display different content, so most of the requests are simply returning JSON content.

It is my understanding that Restful applications should generally not use sessions, or rather that the server should respond identically to identical requests and not have its own data that shapes a response. But if I do not store something in a session variable, how could the server know that the client making the request has the correct permissions? And are sessions not stored in the browser anyway, thus not part of the server?

I believe from what I have read, it is possible to create a token which is essentially a large random string, return that string to the client and also store it in a database with a timestamp. The client then provides this token when making requests and the server hits the database to verify it exists and valid. But would the client not also have to store that string in a cookie? I suppose the angular application could store the token in a variable, which would persist while using the ui-router but not if the users navigates using the address bar.

I also do not understand how Basic Auth may or may not fit into this picture. Any help would be greatly appreciated, as well as a pointer to some good resources where I may find a better understanding of these concepts in general.

ErikAGriffin
  • 730
  • 3
  • 10
  • 20

3 Answers3

1

You want to read up on JWT. There are JWT libraries for Ruby and Angular.

I know you aren't using Node for your backend but a very easy way to see all the pieces working together is to run the angular-fullstack Yeoman generator. It uses JWT and the code is easy to follow.

Andy Gaskell
  • 30,100
  • 5
  • 70
  • 74
1

As far as I can see, whatever you are doing with your sessions can work just fine.

This can be a sample JSON response from the server in case the user is not loged in :

{
"errorCode": 1,
"error": "User not logged in",
"data": {}
}

You can set your own error codes and handle what you want to do. You will send any data only if the user is logged in. For all the pages which don't require authentication, you can set data to whatever you want.

On the angularJS side, you can handle based on error codes, you can redirect the user to the login page and so forth.

The alternate way to support the same on multiple platforms is to use token based approach. The token based approach in simple words work this way.

  1. The user logs in for the first time with his / her credentials.
  2. The server verifies these information and creates a token from which the server is able to decode the user id.
  3. Whenever the client makes the requests, it passes its token with every request.
  4. As the server can decode the user information from the token, it sends or doesn't send the data based on whether that's a right token or not.
  5. The token depends on a secret value. It can be same for all the users or differnet for each based on how you want to implement.

This is all done and you can look at http://jwt.io/

As @andy-gaskell mentioned, you can look at http://angular-tips.com/blog/2014/05/json-web-tokens-introduction/

I'm very bad at explaining. Please let me know if any of this doesn't make sense.

0

you are missing the point of the REST concept. One of the main concepts in the REST apis is that the server should be stateless - this means that you should not store sessions or other "state" in your web server. Every HTTP request happens in complete isolation. Every request should include all data needed by the server to fulfill the request.

But if I do not store something in a session variable, how could the server know that the client making the request has the correct permissions?

You can store request scoped variables. This means that they should be only active during the same request. You can store the current logged in user in the request scoped variable. In that way you can get the current user in your invocation of the business method. I'm not familiar with Sinatra but here is the doc: http://www.sinatrarb.com/intro.html#Request/Instance%20Scope

But would the client not also have to store that string in a cookie?

of course you should store your access token in the client side https://stormpath.com/blog/where-to-store-your-jwts-cookies-vs-html5-web-storage/

as @Andy Gaskell suggest take a look at JWT and fullstack application code generators and forget about the basic auth because it's really "basic".

more useful links:

If REST applications are supposed to be stateless, how do you manage sessions?

http://www.sitepoint.com/php-authorization-jwt-json-web-tokens/

Community
  • 1
  • 1
Nikolay Rusev
  • 3,354
  • 1
  • 17
  • 27
  • "this means that you should not store sessions or other 'state' in your web server". A session is stored in the clients browser though right? What state are you referring to being stored in the server – ErikAGriffin Jun 14 '15 at 15:53
  • Nope, sessions are stored in the web server. – Nikolay Rusev Jun 14 '15 at 15:56