5

After watching the AngularJS "Massive AngularJS apps" presentation (https://docs.google.com/file/d/0B4F6Csor-S1cNThqekp4NUZCSmc/edit), I was attempting to implement the following scenario

1) User requests index.html (Server side generation)
2) Flask checks if authentication cookie is present
3) If cookie is missing, redirect to login.html (also server side generated)
4) On login page, POST the login information.
5) Flask verifies user + password -> sets cookie, redirects to /
6) Flask checks cookie, retrieves user profile + generates index.html
7) Client app starts
8) Client is expected to do a call to /token (with cookie)
9) Flask verifies request, generates new access + refresh token & expires init cookie
10) Client receives tokens & can do normal REST calls with basic auth header using the tokens

The problem I had is was implementing the way of maintaining authentication once the index.html has to be generated. I proposed to include the token in the profile of the index page (as a javascript variable), and when angularjs configures, and copy it to the window.session storage but I'm was not too sure about how secure it is?

Is this is an acceptable flow security wise and/or there better ways?

EDIT: Updated question + Added the flow I would use as a sequence diagram: EDIT2: I noticed I can't reload the page since the cookie will be expired, so I'm starting to doubt the use of access tokens..

Login flow

Busata
  • 1,088
  • 1
  • 10
  • 24
  • Well, just realised that you'll never be able to reload the page, because as soon you get the token, / won't be served without logging in again. Any suggestions? – Busata Jun 02 '14 at 12:40
  • After googling a bit more, I guess it's no issues for my own app to use cookies for authentication, while allowing oauth for the API part. – Busata Jun 02 '14 at 13:50

1 Answers1

3

I'm confused by the complexity proposed in the question.

When I think about user security for webAPI/RESTful projects (regardless of whither angularjs/flask are involved), I think of the following data exchange:

  1. User (via their web browser) submits auth secrets (I.E. User and Password) to web server
  2. Using the above, the Web Server:
    1. creates a non-forgable new secret which it can decode to identify the user (I.E. sign or encrypt a user-record, sessionID-that-includes-login-info, or user-ref-token)
    2. pushes that new secret into the User's web browser (I.E. make the user's web browser store it as a cookie)
  3. All future HTTP/API/REST connections from the client (other then changing user auth secrets) are then done by including the web-server-secret/cookie, either by the client javascript pulling the cookie and including it in the URL/data-body or by letting the web server access the cookie by normal means

Your question seems to be asking about multiple layers of complexity beyond my base case and I don't understand what is necessitating this extra complexity (specifically your "The problem" text and your step #9). If this complexity is needed because of some facet of angular or flask (I.E.: if your having trouble with access to cookies, or your trying to mitigate some other security problem) please explain.

Community
  • 1
  • 1
Mike Lutz
  • 1,812
  • 1
  • 10
  • 17
  • Thanks, I was trying to pose too many questions at the same time. Was focusing on _having_ to use the access tokens while cookies on its own are acceptable as security means. – Busata Jun 03 '14 at 20:52
  • @Busata I'm happy I could help. Yes, while my brain spins at the idea as well, the web auth world is made nearly exclusively of cookies. BTW If are working with Flask you might want to take a look at [Flask-Login](http://flask-login.readthedocs.org/en/latest/), it will do a lot of the login/cookie footwork for you, and if you implement `get_auth_token` it will give you a fairly good security model out-of-the-gate. – Mike Lutz Jun 03 '14 at 21:45