4

I'm architecting a public web API for my service. It will be equally consumed by web pages and native mobile apps (iOS, Android and Windows 8).

Should I use cookie-based authentication? I mean, is this the best practice for this scenario?

Futher Info:
After a little research in the authentication/authorization/openId-connect field i realized that most of everything is handled by the browser, by that i mean, the redirects, coockie insertion and related "boiler-plate" stuff... when i think about all that boiler-plate that i will have to duplicate in my natives apps, i wonder if that model is the best for mobile apps. i mean, maybe theres another more mobile-native-friendly way...

Ps: i know that this is a little generic still, it's just that i'm a begginer in the field of security and i dont know how to properly express my doubts/concerns/"laziness" still...

Leonardo
  • 10,737
  • 10
  • 62
  • 155
  • Please try to add more details. Have you researched some alternatives already so you can name them. What are some individual characteristics of your application. You need to show a little more effort for a succesful question. – Alojz Janez Apr 14 '14 at 16:43
  • @AlojzJanez check it out... if not good enough, could pls ask me questions so i can answer??? i think that maybe that way i can arrive at "rich-question status" faster... – Leonardo Apr 14 '14 at 16:51

1 Answers1

2

The API itself should really be stateless, and not manage any sessions. Each request to an API should be made with the authentication details (e.g. OAuth token).

If the Web pages and mobile applications need to maintain some kind of session, then it should be up to them as clients of the service to maintain that state. For instance, a Web page might set a session cookie for the user, but a native mobile app might want a completely different approach.

See also: If REST applications are supposed to be stateless, how do you manage sessions?

Community
  • 1
  • 1
cmbuckley
  • 40,217
  • 9
  • 77
  • 91