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

2
  • 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? Commented Jun 2, 2014 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. Commented Jun 2, 2014 at 13:50

1 Answer 1

3
+50

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.

Sign up to request clarification or add additional context in comments.

2 Comments

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 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, 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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.