We're using a cloud based web security (proxy) service which basically takes our web requests, scans them and NATs these requests to their public IP addresses. NAT is being done on a per-session basis, whatever that means in detail.

We now have a problem with a third party service which is essentially doing something like this:

  • User goes to URL A (TLD 1) and logs in there
  • The login then sets a cookie with no domain set (so its only valid for this domain)
  • It 302 redirects the user to another Domain URL B, and sets some token as GET parameter

At this point the session is rejected with an error message that the public IP does not match (for the proxy its a new session, thus a new IP address is used when NATing this to the outside)

For me this looks like a way to authenticate the user on one site and using services on another without implementing some proper authentication framework.

My question:

Is this IP address check adding any (noteworthy) security? This seems to be a setting we cannot change on the security provider side, so we may need to convince the provider to change this model.

1 Answer 1


It is unclear from your description if the authentication is done solely on the IP address or if the IP address is an additional security measure but I rather believe that it is used additionally.

If the IP is used as the only authentication it would be pretty weak although maybe sufficient depending on the kind of security actually needed for the service. If the IP address instead is used additionally to existing security measures than it actually increases security since it reduces the risk of session hijacking. Session information are in this case likely encoded in the redirect URL and kind of protected against misuse by encoding the clients IP address too.

You must log in to answer this question.

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