Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

How to handle user authentication persistance in IOS?

I'm trying to build the foundation for my iPhone app and server. I have users who will sign up and sign in from the iPhone app. In a normal website login, the http server will provide cookies to allow the user's subsequent requests to remain authenticated. How should I handle this on the iPhone? Should I just send the user/password every single time I have a NSURLConnection GET or POST? That seems excessive. Or do I use the ASIHTTPRequest framework to use cookies. Can anyone point me in the right direction for a proper implementation?

Thanks!

like image 928
Ryan Avatar asked Feb 12 '12 21:02

Ryan


People also ask

What is AuthState?

public class AuthState extends Object. Collects authorization state from authorization requests and responses. This facilitates the creation of subsequent requests based on this state, and allows for this state to be persisted easily.

What is firebase persistence?

firebase.auth.Auth.Persistence.SESSION. 'session' Indicates that the state will only persist in the current session or tab, and will be cleared when the tab or window in which the user authenticated is closed. Applies only to web apps.


1 Answers

Sending username and password in every request is not great.

You can use anything you want to send cookies. It's just another HTTP header. But that begs the question of what is in the cookie. It depends on what your client/server architecture is. Web apps use session keys because traditionally web clients haven't held any state so the app server had to. Native clients can have all sorts of state and so generally don't need the server to provide that.

But you need authentication. That's what things like OAuth and OAuth 2 are for. They allow you to authenticate once and then use tokens that can be invalidated server-side. Kind of like very long lived sessions without data.

They are a bit complicated but there are open source libraries for both the server and client pieces or you can roll your own. Most of the complication is on getting the original token which you can short-circuit if you own the client and server. OAuth can get pretty complicated because all requests are signed with a secret token. OAuth 2 can be as simple as a shared secret (thus requiring SSL) in a cookie.

like image 195
smparkes Avatar answered Nov 14 '22 20:11

smparkes