Feature: We would like to invalidate the session of the current logged-in user if their IP changes.
Description: As part of a recent security audit, the pentesters found an issue with the fact that the user session is still valid when the IP changes. This allows for session hijacking. Ideally, we could easily toggle an option in the auth0 configuration that automatically invalidates a user’s session if the system detects an IP change.
Use-case: Prevent system access during client authorization flows if the IP address differs from that which was used during login. Make this session-specific - such that the user can log in on multiple devices/different IPs - but if the IP changes for the device, that specific session is invalidated.
Current workaround: The Auth0 support team has been very helpful with iterating on a solution that works, with some limitations. They also suggested that I post a request to this product feedback forum for review. Their final suggestion is one that we are going with, for now:
I wouldn’t say we have such a mechanism i.e. get the stored ip address (from initial login) from the previous access token which has now expired however maybe we could take a different approach. Maybe we can store the initial ip address in the app_metadata against the user at first login then on the silent auth call (use the login type) use the ip address from app_metadata instead of taking it from the context object, we would need to watch out though as the management API rate limits may become a bottleneck if there is a lot of traffic with many users logging in and we’re writing to the users app_metadata.
We may also need to look at the user’s device e.g. a user may use mobile on a personal wifi and their computer may use the company VPN, the user may want to login with two devices at the same time, maybe this scenario is ok in which case we may need to keep an array of valid ip addresses for the user at initial login per device.
This solution is nice, and we can build it using actions. However, it creates some cumbersome code - especially when it comes to invalidating IP addresses so that the list of IPs does not grow indefinitely. Since there is no good way to tie a session to an IP address, we would have to store a more complex object containing IP info, device info, and login time and add some more logic to remove the IP / invalidate the session on subsequent requests if the device matches and an expiration time has passed, relative to the configured inactivity/absolute session timeouts.
Please consider this enhancement so that our solution can be configuration-centric and handles all of the edge cases.
Appreciate the consideration!