Log user out after change of IP address?
If you want to implement a security measure, you need to know what you secure yourself against. In this case, you want to secure yourself against a Man-in-the-Middle attack.
As you said yourself, a change of IP address is not a good indicator for that, for actually two reasons:
- There are many reasons why an IP address would change for legitimate reasons, such as the user gaining or losing a Wi-Fi connection, the user connecting to a VPN, etc. As such, this alone is a really bad indicator for an attack.
- For the detection to work, it assumes that a user first starts a session on their own, and is then intercepted by the Man-in-the-Middle. If your user is already being intercepted, the IP of the Man-in-the-Middle is the only IP you will ever see.
As such, this security measure is rather prone to false-positives and false-negatives, making it rather unreliable.
But there is a security measure employed by Google that works in a similar way. It detects the usual behavior patterns of a user, such as the usual locations and IP address ranges they connect from. Should a login deviate from this pattern, a security alert is triggered.
This is most prominent when users want to check their emails on vacation or similar, but can truly be an indicator of possible compromise if the user's regular usage patterns are clearly established.
This should be an example as to how information from IP addresses (and other sources) can be used to analyze behavior and thus detect anomalies. Anomaly Detection is a field all on it's own, so don't expect a comprehensive introduction in one paragraph. This example should merely serve illustrative purposes.
The only consideration is the one of risk.
Controls (like this control) are put in place to mitigate risks. What risks are you trying to mitigate? You say that it might mitigate MitM. Ok. Is that your web service's responsibility to do that? Does it make sense for the service to do that?
Then let's consider the actual scenario. Your control mitigates MitM if the attack happens after the user has already logged in. That's pretty specific and a really limited threat. Let's keep running the scenario. The attack happens and the service logs the user off, then the user logs back in. But the attack is still happening. So, now the attacker captures the login process and the password. Have you met the goal of the control? Some of these things might be mitigated by other controls you might have in place.
Also consider the risks of poor usability. If you install a control that makes it difficult for users to use your system, then you run the risks of losing users.
What is the best decision for you is up to you and all the factors you can't include in a question on a Q&A site.
Risk assessments are really straightforward. You just need to slowly connect the dots one by one and resist the temptation to jump to the end.
Hard no.
Security considerations aside (which this practice does not really help), restricting a session to an IP address utterly breaks access for users of some ISPs, especially mobile, who cycle IP addresses frequently. IPv6 even has features to do this intentionally for privacy. Unless you know your userbase well and know that none of them will be affected by such issues, it's a complete non-starter.