Since the beginning, BunnyCDN has offered the industry standard token authentication. It allowed users to sign a single URL and optionally set the IP limit and expiration time outside of which the URL would no longer be accessible. It was a very simple, but powerful way of content delivery control.
Throughout the years however, some flaws started to appear that made the system impractical in certain situations. The two most prominent ones were the lack of path based tokens and the inability to sign URL query parameters. One token was simply used for a single URL.
The outdated standard just wasn't cutting it anymore and we wanted a better solution that was just as easy to use, but allowed more control and flexibility.
Token Authentication V2
Based on what we've learned, combined with the feedback from you, we went into action to design a new system and we are happy to announce Token Authentication V2!
It's a big upgrade over the old signing system with more security, more features while being just as simple to use.
Here's what's new:
The original system used MD5 based hashing to calculate the tokens. While being simple and fast, MD5 is getting a bit old. So old in fact, that a single modern graphics card can generate over 50 billion hashes per second, which is not inspiring much confidence. As such, the first thing to do was to switch from the old MD5 system to something a bit more modern. In the end, we decided to go with SHA256. While also very fast, it is still much safer than MD5 and will make it much harder for an attacker to brute-force your security key.
As one of the main updates, we added a new token_path parameter to allow you to optionally specify the URL path that will be signed. This can be either a directory, single file or even the whole domain. It's a powerful way to allow access to more than one file without having to regenerate the tokens for each one. A real-world example for that would be a HLS playlist and the video files it's linking to.
URL Path Based Signing
The next big update is the URL path-based signing. With the original Token Authentication, the token had to be passed as a query parameter, which could cause issues in some situations where multiple files needed to be loaded from the same path by the browser or where query strings were not able to be used.
To solve this, Token Authentication V2 allows you to sign the request both with a query string or as part of the URL path structure instead, for example:
If a browser makes a request to any subsequent relative URL inside of that path, it will also automatically copy the token from the path and authenticate the next request.
Combined with the token_path parameter, this presents a powerful solution to HLS video delivery. Developers can now easily sign a single HLS playlist URL, and the browser will automatically sign any subsequent requests to files inside of that directory.
Query Parameter Signing
The original system disabled vary cache based on the Query Parameters because the tokens would change with each request and cause nothing to get cached. This also created a risk where anyone could modify the extra query parameters to pass whichever value to the origin.
Token Authentication V2 solved this by including the query parameters into the token as well. In order to verify an URL, all the query parameters must also match the generated token. Any change to those parameters, will result in the request being rejected.
This is useful if you want to use the token signing in combination with Bunny Optimizer or even to secure a web API.
IP Range Authentication
In 2020, the internet is a dynamic place. Mobile devices can change IPs even as often as between each request. Originally, the token authentication only allowed you to generate tokens for a single IP. We now allow you to generate a token for a full /24 subnet by replacing the last digit with 0, for example 22.214.171.124.
This reduces false negatives if the user's IP quickly changes and can also have a positive effect on privacy as the full IP is not needed to be known.
Whitelisting And Blocking Countries/Referrers
Based on your feedback, we also added an ability to whitelist or block a list of countries or referring websites. This allows more control when generating tokens that don't specifically require to be limited to a single IP, but still need regional restrictions for example. It's also a great way to prevent hotlinking already signed URLs that an external website would scrape from your HTML.
Get Started With Token Authentication V2
Token Authentication V2 has already been automatically enabled for every zone and has already been in heavy use for a few months. The system is completely backwards compatible and our servers will automatically recognize between the old and new token authentication.
If you are already using the old token authentication system with good results, that's great and it will continue to work just fine. We plan to support the old token authentication side by side to V2. If you are just looking into this however or want to upgrade to the new system, we have new guides and code samples ready to help out:
This has been a heavily requested feature and we are finally excited that it is fully available. It's bringing a much more powerful way to securely deliver content through a CDN and we're looking forward to seeing what you build with it.
If you have any questions, feedback or need help with the new implementation, please let us know and we will be happy to assist!