Firstly, apologize if i posted this question on wrong category or not related at all. I need advise related my sample application, here is the plunker:
Question:
I created sample login app that in the end i want to integrate it with Phonegap (for IOS app). I want to know about Storage (Session / Cookies) strategy that i can implement in Login mechanism. Basically i want to know whether “$window.sessionStorage” is supported by Phonegap? I want create login mechanism like pinterest / Instagram, if user already logged in then don’t need to re-logged in again. I don’t know how “$window.sessionStorage” will be handled in Phonegap.
Your best bet is to NOT use cookies for an actual app. You are better off using tokens. It’s really not much of a difference. Essentially, the user logs in. You then respond to the login request with a token in the response. Your AngularJS then stores that token locally. Then, on each new request, add that token to the headers.
As I said, it’s very much like cookies. However, you manage it instead of relying on HTTP for it. There are some advantages as well. The biggest being that CSRF attacks are eliminated. Unlike with cookies, someone can’t use an image link to cause an event on another site. This is because the token will not automatically be passed with the image request.
I actually needed something like that for a few apps I’m working on. I spent quite some time investigating this and was able to achieve something I was happy with.
In addition to email/password authentication I’ve added some social authentication which kind of works in the same way.
@Calendee how did you send the token back from the server? Currently the cookie is being set by the session infra in webapp2 (App Engine), and the session infra checks the session id. Would I have to replicate this whole infra (check with every API call)?
You can do that. It depends on your circumstances. If the API gives you a refreshed token, then store it and use it for all subsequent requests. Long life tokens are pretty common.
@Calendee
and for apps that involve payments, a long life token still a good ideia?
it’s great that localStore eliminate CSRF threat,
but it’s also leave the value accessible on the phone files, so this can be accessed from any other apps?
how i would prevent from this token to be used for anything bad?(even if isn’t accessible from other apps)
i was thinking in asking a second smaller password or the same, each time the user want to confirm a transaction…
there are a list of threats that can be harmful to hybrid apps, with all data stored in localStorage systems?
I’m no expert on the matter; so, you’ll need to evaluate the risks yourself. Depending on the sensitivity of the app/data, you may find that users will NOT want to be prompted for a password all the time, while others will insist it’s necessary. So, you need to make a decision that balances security vs. ease of use.