Why You Shouldn't Tie IP Addresses to Tokens
Locking tokens to the client IP address might seem like a good way to prevent content theft, such as sharing of authenticated URLs that include tokens. It might even appear to work in small-scale test environments. However, the internet has evolved to a point where it’s quite common for clients to use multiple source IP addresses. This is especially true when a token is created by a server on one hostname (such as a CMS) but then validated by a server on another hostname, such as an Akamai edge server, when serving content.
Akamai strongly recommends against tying tokens to specific IP addresses.
In this example, 1) the client requests a token from a CMS or auth service and takes a path causing it to have a client IP of 192.0.2.1, 2) this IP address from the first network path is included in the token, and 3) the client sends the token to an Akamai delivery service, but this time it takes a network path causing it to have a client IP of 203.0.113.7 when connecting to the Akamai delivery service and thus gets denied.
Situations that pose an issue
The following may all result in clients using multiple source IP addresses over a short period of time:
Network address translation (NAT), including CGNAT (Carrier Grade NAT). Most mobile and enterprise networks and an increasing number of residential networks use NAT to allow a large number of clients to exist behind a smaller pool of IPv4 addresses. It is very possible for clients to have multiple different source IPv4 addresses for individual connection requests, especially when the NATs are under load. This is commonly encountered during large events, including large events unrelated to Akamai or your hostname.
Apple iCloud Private Relay. The Apple iCloud Private Relay service improves end-user privacy by hiding the client source IP by sending requests through a pair of proxy servers. The source IP that the Akamai CDN sees retains geography. Apple has an authenticated way to send the country, and this is included in the source IP from the Private Relay service. There is no guarantee that the IP will remain stable, however. This is especially problematic when requests setting a token go directly to a server but where use of the token goes through Private Relay. This can happen for hostnames under akamaized.net and akamaihd.net. Moving hostnames off of the Akamai “shared certificate” is not adequate, as iOS/OSX clients that have explicitly enabled Private Relay will continue to send all traffic through the service.
IPv4+IPv6 dual-stack clients. Clients that have both IPv4 and IPv6 connectivity may switch back and forth between them, making the client appear to have more than one IP address. This will especially be the case when a token is set by an IPv4-only host, and validated by an IPv6-enabled host, or vice versa. Even if both hosts are IPv6-enabled, clients may sporadically switch between IPv4 and IPv6 due to network conditions. Given the performance benefits of enabling IPv6, it can be considerably faster in some networks and countries, so it is preferable to IPv4+IPv6 dual-stack content wherever possible. IPv6 can also provide finer-grained geo information with Apple iCloud Private Relay than is possible with IPv4, which is yet another reason to dual-stack content. Locking tokens to client IP addresses is one of the most common reasons for customers to keep sites IPv4-only.
IPv6 privacy addressing. Clients using IPv6 will typically change their IPv6 address a few times per day, usually within the same /64. As a result, tokens will break if they are set and used during one of these transitions.
Clients switching networks. Clients switching networks, such as a user walking out the door and transitioning from their home Wi-Fi to their mobile network, will switch their IP address. It is possible that this sort of behavior will become increasingly common with 5G. There are also some mobile devices that will balance traffic between mobile and Wi-Fi networks to improve performance.
Proxy servers and secure web gateways (SWG). It is common for enterprise environments to use proxy server pools and SWGs, including some of Akamai’s security products, that have multiple instances with multiple back-end IPs. The client source IP will switch when the client switches between instances. In the past, this might have been remediated through using IPs from the X-Forwarded-For header, but this typically isn’t applied for HTTPS traffic, which now represents the majority of internet traffic.
Casting a stream to a set-top box or TV. When a viewer uses a “Cast” or “AirPlay” feature to send a stream to be played by another device in their home — such as a smart TV, AppleTV, or Chromecast — requests from the new device could start coming from a different IP address. This could be due to many of the reasons above, i.e., a different IPv6 address, switching from IPv4 to IPv6 or vice versa, or the phone using a Relay/SWG/VPN or other path not used by the cast target. In some cases, the device has different internet connectivity, as with some ISP-provided set-top boxes.
The list above is only a subset of known use cases that continues to grow. Because of this, it is strongly recommended to NOT tie tokens to IP addresses. Doing so may result in a poor user experience that may not show up during testing, or which may only show up during events. It is also recommended to IPv4+iPv6 dual-stack content, which is contraindicated by tokens tied to IP addresses.
Recommended approach
Follow the Token authentication instructions in Akamai’s product documentation: Example 1, Example 2. Akamai’s recommendation has remained the same for some time, but is often overlooked.
“We recommend against including the IP address field in your tokens to tie the token to a specific IP address — unless all requests will only come from a specific address. This can break delivery in a property if requests come from other IP addresses or if you’re using an IPv4+IPv6 dual-stacked environment.”
Alternatives
Place session ID or other unique identifiers into the token.
Use Akamai’s Managed Content Protection service to identify token sharing and token abuse. Akamai’s Access Revocation, a product option for Adaptive Media Delivery, can also be used to block access to content in near real time.
Not recommended: Associate the token to a particular “User-Agent” string. These should be more stable between given requests from a client. Note that this will still break with the “Cast” and “AirPlay” case listed above, and browsers such as Chrome are also planning to freeze the User-Agent string.
Akamai does not yet have a service that can automatically validate that tokens are only used a small number of times, but we are exploring options in this area, as well as other future possibilities.
While precautions have been taken in the preparation of this document, Akamai Technologies, Inc. assumes no responsibility for errors, omissions, or for damages resulting from the use of the information herein. The information herein is subject to change without notice.
