Looking at Gmail's cookies it's easy to see what's stored in the "remember me" cookie. The username/one-time-access-token. It could be implemented differently in cases where the username is secret, as well. But whatever... the thing is not very high security: you steal the cookie and you're ready to go.
My question is on the functional side, however: when do you wipe their access tokens? If a user logs in without clicking "remember me" on another machine, should it invalidate their access tokens on all machines? I'm asking about how this is traditionally implemented, and also how it should be implemented.
I regularly use 2 or 3 machines simultaneously, and have "remember me" on all of them. If one of them disconnected the others that would be very annoying, so I wouldn't recommend it.
Traditionally it would use a time-out, the cookie expires after a certain length of time (or when the user signs out).
It all depends on your security model. If you are writing an internal company application where you only ever expect one user to be on one computer then you might want to have tighter restrictions than gmail.
Also, bear in mind the possibility of Denial of Service - if an action on one machine can force another machine to be unusable this could be use to prevent a legitimate user from taking control back in certain scenarios.
The articles Persistent Login Best Practice and Improved Persistent Login Best Practice are great references on how to implement this sort of functionality.
See also these StackOverflow questions
Logging on from another machine should not invalidate the login associated with a cookie on a different machine. However if the users logsout or "not you? login here" this should clear the cookie on which the user is working.
By the way stealing a cookie can be made hard, by insisting on https and making it not for scripting.
By adding "; HttpOnly" to the out put of your cookie this will make the cookie unavailable to javascript e.g.
HTTP/1.1 200 OK
Cache-Control: private
Content-Type: text/html; charset=utf-8
Content-Encoding: gzip
Vary: Accept-Encoding
Server: Microsoft-IIS/7.0
Set-Cookie: ASP.NET_SessionId=ig2fac55; path=/; HttpOnly
X-AspNet-Version: 2.0.50727
Set-Cookie: user=t=bfabf0b1c1133a822; path=/; HttpOnly
X-Powered-By: ASP.NET
Date: Tue, 26 Aug 2008 10:51:08 GMT
Content-Length: 2838
you can read more about this
The remember me cookie should identify the machine as well. It should be related to the machine because there are places where you want to be remembered and other places where you don't (home vs work).
Expiration date is set usually to a reasonable period (two weeks) or after the user has explicitly logged off from the machine,
What I would do is link each session to an IP address. If the a session token is sent from a different IP than you have for that, reject it.
Access tokens should be IP specific so that they can not easily be transferred across machines.
They should also be implemented in a way that allows users to see what machines they have active tokens on.
Sites that choose to kill off a token once a new one is created on another computer - make the choice that their users will not access their service on multiple computers - or if they do - that their usage justifies making them login again.
The policy you employ really depends on the data you are holding and the needs of the user.
来源：https://stackoverflow.com/questions/1074831/remember-me-on-this-computer-how-should-it-work