My web service is an API-driven Single-Page-Application. Once the user logs in they're given a temporary token to use for the rest of the session which is sent along with each API request. The token is of course tied to the IP address that performed the login request. This means that even if a 3rd party somehow managed to capture a token despite TLS, they probably couldn't use it and it wouldn't be usable by anyone at all after the current session ended.

But I recently came across a user whose IP address changes with extreme frequency (as frequently as every 30 minutes) causing them to frequently need to re-log-in while using the service. The address change is caused by on-campus dorm internet that recycles a very limited pool of IP addresses that the end-user of course has have no control over.

How can I reconcile keeping the security of my current setup, while also not causing users in this situation grief? The best 'middle-ground' I've got so far is loosening the IP requirement to only match the first octet of the address, but that's far from ideal.

  • Are you able to allow IP ranges? For example, 192.168.1.* instead of From my perspective, it also seems like relying on this IP address method is pointless. Commented Feb 4, 2016 at 17:45
  • How about adding an option (possibly in the user's Account configuration) to grant longer lived sessions?
    – Purefan
    Commented Feb 4, 2016 at 17:45
  • @Purefan It's not the session length that's the issue, this isn't a 'remember me' tag - this is while the SPA is still open in the browser in the same session. The users IP changes and suddenly their login token isn't valid anymore because the service sees them as coming from a different IP address.
    – PhonicUK
    Commented Feb 4, 2016 at 17:47
  • @MarkBuffalo These are coming from external IPs and the range of change is really wide, for this particular user the last 3 octets change - if I allowed a range that wide I might as well not bother caring what IP address requests come from and only care about the token - but that's a step down security wise.
    – PhonicUK
    Commented Feb 4, 2016 at 17:49
  • @PhonicUK Yeah, I used a local IP as an example, not internal ones. Sorry, should've clarified that. Commented Feb 4, 2016 at 17:51

2 Answers 2


I am inclined to say that the bit about tying the session token to the source IP address is harmful and should be removed.

Such a tying is often reported as "good for security", but exactly why it is good for security is rarely explained. It is similar, in that respect, to the widespread recommendation for changing your passwords regularly: a well-entrenched Tradition, for reasons that nobody quite remembers, and with toxic side-effects.

The main reason why session tokens are to be tied to an IP address is not to prevent reuse after theft through the TLS layer. Let's face it: if an attacker could break through the TLS, then a filter on the IP address won't block him either. Such an attacker could so much hijack the user's connection that he totally owned it; masquerading with the user's usual IP address will not deter such an attacker.

The real reason for tying the session token to the IP address is to try to prevent a user from sharing his token with all his friends. This is a commercial issue, similar to software licensing. It is normally best addressed with surveillance: instead of blocking session tokens that do not come from the same IP address as previously, you should merely log such an attempt (but still allow it), and, asynchronously, investigate situations where a token appears to be used by too many source IP addresses.

  • There's nothing stopping the user from logging in multiple times in multiple locations, that's fine - the token is used purely for the integrity of the current active session in an open (and remaining open) browser window. But I get your point that if the login token has been stolen it's probably too late to care about measures anyway.
    – PhonicUK
    Commented Feb 5, 2016 at 12:29
  • 2
    I completely agree that tying security to the IP address is the wrong approach and isn't providing the integrity you may think it is. NAT is extremely common and many people and devices will have the same IP address. Likewise with somebody walking around a business or campus or walking out of their house, where their IP address may change as they hop around to different network nodes or even different internet providers (wifi to 4G and back, for example). Commented Oct 18, 2016 at 4:10

I understand the reasoning behind wanting to tie the user's session to an IP address. However; as mentioned by others, Internet Service Providers lease out IPs frequently and the IPs are dynamically allocated and can change anytime.

Another approach you might consider is to use the User-Agent header data instead. You can store this information upon initial login request. This way if a user changes devices or shares their token you are "most likely" able to detect this change on subsequent requests and decide wither to allow/deny the communication or revoke the session altogether.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .