1

It seems that cookie based authentication is the clear choice today for web services that require login credentials.

But what about if you're developing a web service where the clients are not browsers, but client software (such as a mobile App) that accesses resources via HTTP, would you use HTTP authentication or cookie authentication?

HTTP Auth:

  • Web server handles authentication, so easier to change web app platform if needed
  • Automatically applied to non-code resources (e.g. JPG, XML, etc) (Side Q: Is there a way to do this with cookie-based auth?)
  • Harder to integrate database-stored credentials with server auth (.htaccess/.htpasswd)

Cookie Auth:

  • Fine grained access controls (a code resource can respond differently based on credentials)
  • Control over expiration of session (via cookie expirations)
  • Full control over user login experience

What other considerations am I leaving out? Any other Pros/Cons?

Some helpful discussion is here

jpeskin
  • 2,801
  • 4
  • 28
  • 27
  • If interested in security between these two types of authentication read this: http://stackoverflow.com/questions/5052607/cookies-vs-basic-auth/5052622#5052622 – Marco Demaio Apr 29 '11 at 15:47

4 Answers4

1

With HTTP authentication, a code resource can respond differently based on the user who made the request. The name of the user is usually passed to the code via HTTP header.

With HTTP authentication, you can still use sessions and have the same benefits that they bring. In fact, session stealing is not that much of a problem anymore, because you can test whether the user that is stored in the session is the same that authenticated via HTTP authentication. For the same reason, session identifiers need not be that unguessable as they need to be with Cookie based authentication.

Oswald
  • 31,254
  • 3
  • 43
  • 68
  • Good points. However, you say that "session stealing" is not a problem. Are you referring to sniffing HTTP packets and copying the session cookie? It seems that HTTP Authentication is just as vulnerable, as user:pass are transmitted in [easily decodable Base64](http://en.wikipedia.org/wiki/Basic_access_authentication). It would be only slightly harder to steal HTTP Auth credentials, if transmitted via HTTP. Or am I not understanding your point? – jpeskin Feb 09 '11 at 18:46
  • With HTTP authentication, the session identifier is of little use (because he is denied entry by the webserver before the web application even starts up and has a chance to look at the session identifier). The attacker would also have to know the username and password. On the other hand, to be authorized, the username and password must be transmitted on every HTTP request. So yes, packet sniffing is just as dangerous as with Cookie based authentication. I was talking about things like sharing a link with a session identifier. – Oswald Feb 09 '11 at 19:40
0

HTTP basic auth is a nightmare when the password gets compromised, as there's no way to change it without changing all the legitmate clients first. You also can't force an individual user to be deauthenticated, and the mechanism for transmitting the authentication credentials is insecure (unless you wrap it in https)

Really, your best option is to use a cookie based system, allowing granular control over individual authenticated sessions

smeenz
  • 3
  • 2
0

Well, when client is a mobile app or something that is not an ordinary browser, a server app still needs some kind of session tracking. The simplest way to perform the session tracking is to use some kind of "cookies", either standard HTTP cookies or custom session IDs. So, a session identifier is effectively a "cookie" even when a standard cookie mechanism is not used. I always assign session identifiers to client sessions, so I tend to vote for cookie auth.

Alex
  • 907
  • 2
  • 8
  • 22
0

Seems there is no "HTTP authentication versus cookies" nowadays: none of my browsers (Firefox, Opera, Chrome, Edge, ...) even asks me for HTTP authentication, if I disable all cookies. That's some kind against the RFCs, I guess.

LElsner
  • 1
  • 2