This documents observed IP Address behavior on both Verizon and AT&T data networks.
If you have an authentication scheme that relies on some level of the client's IP (Internet Protocol Address) maintaining state during the process then you should be aware of the potential that the client IP is different between regular HTTP and HTTPS (Secure HTTP) when that client is accessing from a 3G/4G data network. A real world example: on the first request/page-view on HTTP, you may see the client IP as 18.104.22.168 and on the second from HTTPS you may see 22.214.171.124.
Often an authentication scheme will use that IP address as a partial internal key or as additional verification to increase security and limit DOS (Denial-of-Service) attacks. An authentication scheme that relies on that IP address remaining the same at any given point, will have to be adjusted for the behavior of phone data networks.
There are four strategies to adjust.
First, if reasonable and not truly needed, is to adjust the scheme to abandon IP address as a key or verification step altogether.
The second, noticeably adopted by many sites, would be to use HTTPS for all requests/page-views after initial log-in. In that case, all the requests end up coming from a constant IP address.
The third alternative is to maintain the mapping from HTTP-IP-Address to HTTPS-IP-Address back to HTPP-IP-Address. In this case, the scheme would consider that a valid transition if it ends up back where it started from. Any transition in a reasonably short time frame would not be suspect.
The forth option is to loosen the rules of IP match to only use the first two octets of the IP address to match. In other words to only key off the Class B. So in the above example, 166.137.*.* does indeed match 166.137.*.*. Again, any authentication across a Class B in a reasonably short time frame would be considered valid.
Moreover if you are using a Geo IP look-up database already when servicing a request then for both the third and fourth options you can also only allow that variant behavior from those known data networks.
As an interesting aside, if one was so inclined to try to measure how many users are actually using a given resources from a data network, even a service that doesn't normally use HTTPS, then one can send a small request, such as an pixel/web beacon, to your service via HTTPS and see if the IP address in that request matches the IP address in the base HTTP. The ones that don't match are extremely likely to be from devices on a data network.