Question

Is there any reason why I shouldn’t use cookies/sessions for native mobile applications, usually used by browsers, to authenticate with my server and for subsequent API calls?

Clarification: It seems the de-facto method of authentication on mobile clients is token based systems like OAuth/XAuth. Why don’t traditional browser methods suffice?

Answer 1

This depends on your application (your threat scenario to be more exact).

Some of the most common threats are
– eavesdropping (-> should encrypt)
– man in the middle (-> must authenticate other party)
– …what are yours? (how secure is your cookie store,….)

A cookie at first only holds a token as proof that sometime you have successfully made an authentication. If the cookie is valid long enough or transport not encrypted, there is a good chance that someone someday will find out…

In addition you must take into account what additional security measures are in place, at first and most important SSL.

What is your authentication method (what credential does a client need to logon)? Do you have the possibility to work with authentication based on PPK infrastructure or is the communication “ad-hoc”?

EDIT

Wrt. to OpenAuth: as far as i understood the protocol its main concern is authentication delegation. A scenario where you authorize an agent to do some very specific task on behalf of another identity. This way you dont scatter your credentials all over the web. If you have OpenAuth in place, a client can use the protocol directly, too. So why bother adding another. But OpenAuth explicitly states that with a direct client scenario you again run into security issues as now the token is available on the device and must be protected accordingly (as you must do with your cookie).