[WA]

Good article, but one thing is explained in a weird way:

Don't bother with cookie expiration. That's the wrong approach, because the cookie is controlled by the user. Always do a server-side check whether or not the auth token in the cookie is allowed to continue the session.

So you could simply set the expiration date for a cookie until 2030 but make sure that the auth token from that cookie cannot be used after $EXPIRATION_TIMESTAMP on the server.

You could also follow a layered approach:

If the user logs in every few days, re-authenticate him using the auth token from the cookie. But if the user was seen more than $MAX_INACTIVE_DAYS ago, do not re-authenticate and terminate all sessions, even if the "remember me" function is set to half a year or so.

[bigiain]

I wouldn't go as far as "Don't bother with cookie expiration.", but you're certainly right in that you can't _rely_ on "the browser" to honor them (or even actually be a browser).

I'd still recommend setting reasonable expirations, even if it's only to be seen to be doing the right thing. Far future expirations aren't useful (as you explain) and they only serve to make it look like you're "doing in wrong". (And, for the 99.9% case of non-malicious regular users, expiring the cookies normally saves the sever the effort of looking up the session state of an already expired session with a 2030 expiry cookie. Don't _rely_ on it, but take advantage of it working right under normal conditions.)

[WA]

Good point. Especially the "make it look like you're doing it wrong". You don't want to look like a data kraken in the eyes of customers.

[kijin]

Good point, but your explanation is also a bit confusing. If I understand correctly, your point is not so much "don't bother with cookie expiration" as "don't trust cookies to expire when you tell them to". In other words, the server should double-check cookie expiration dates because you don't want somebody fudging your 7-day cookie and using it to log in next year. Am I right?

[WA]

Technically, the server cannot check cookie expiration dates, because they are never transmitted to the server. Only the cookie content is transmitted.

What I mean is: On the server, you receive an auth token that comes from the cookie. Do the logic whether or not that auth token is valid and may be used to re-authenticate the user on the server only and handle the entire logic for expiration on the server.

Do not rely on the fact that the cookie itself is present, because the user might have fiddled with the expiration date.

[j_s]

Implement cookie expiration server-side.

[jessaustin]

Would anyone be tempted to do this "client-side"? What would that even mean, besides what the browser does automatically? Or are we just saying, "don't trust that the client won't send expired cookies"?