Improvements to Delegated Tokens

We’ve made some big changes to delegated tokens.

Background

Delegated tokens work as a public API token - allowing your customers to upload into your api.video account without actively using authentication. This greatly simplifies the upload of videos into the service.

There has been concern from some of our customers that this upload function could be abused by users who would upload many videos into the account - incurring unexpected encoding costs. So, we are adding some features to the delegated token endpoint that serve to enhance the security of the delegated token feature.

Search delegated tokens

Using this endpoint, you’ll receive a list of all the delegated tokens in your api.video account.

Delete delegated tokens

As of today, any delegated token can now be revoked/deleted. Simply add the delegated token ID you wish to remove into the url, and send to this endpoint to remove the token.

New tokens can have a ‘time to live’ (TTL) for token expiration.

When you create a token, you can now specify how long the token is valid.

The TTL parameter allows you to create a token that is valid for a specific period of time (in seconds). After this time has elapsed, uploads using this token will fail.

A TTL value >0 indicates the time in seconds that the token will remain active. After the token has expired, it will no longer appear in the token search.

If a video has started upload while the token is still valid, but continues past the expiration time, the video will be allowed to complete, and will be added to your api.video account. This also works for video uploads broken into byte ranges.

A value of 0 indicates no expiration. This is the default entry, and all existing tokens (with no defined expiration) have a TTL = 0.

Give our new delegated tokens a try - if you have any suggestions feel free to leave your suggestions here!

2 Likes

A TTL of 1 still gives a malicious user enough time to start an arbitrary number of uploads (however many they can kick off in parallel in one second) and then continue them past the expiration time. For UX though you’d want to set the TTL to 5 or longer which makes the malicious upload problem worse.

I would like instead to be able to create a video record on the backend (so I can set the metadata) and provide a delegated token for uploading to that video ID only.

Hi Austin,

Thanks for posting. That is certainly a valid usecase for delegated tokens. Would you mind suggesting as much on our roadmap? http://roadmap.api.video/

In the meantime - know that the first segment of video must be successfully delivered inside the TTL of the token, so if a malicious user tried to kick off 500 uploads, they would have to successfully upload 500*chunksize bytes of video within the TTL of the token.

Thanks,
Doug

2 posts were split to a new topic: How do I start in Livestreaming

We probably discussed this in my support ticket a while ago but I’m having trouble accessing that conversation; the support chat button isn’t appearing on my dashboard (in the browser console I see a few errors about the script-src Content Security Policy, Firefox 85 on Arch).

What’s the minimum chunk size? I think you mentioned that the first chunk needed to at least contain the full header for the given container format, so, a couple kilobytes or less, typically? That could potentially allow thousands of uploads to be initiated in a single second, if the attacker’s internet is good enough (imagine doing it from a compromised VPS or rented cloud instance with symmetric bandwidth of ten gigabits).

And since pricing is based on minutes of video, they can just upload something that compresses ridiculously well like a black screen at 1 FPS; a dedicated attacker could easily run up a bill of tens of thousands of dollars for one unlucky customer in just a few minutes. I’d gladly throw together a proof of concept if I had the time.

@austin

I understand your concerns. As we continue to evolve the product, I am sure the token attached to the videoId will be considered as a feature to be added.

If you don’t feel comfortable with the current implementation of the delegated token, you can use the more traditional upload that uses the apikey/authentication token.

Unfortunately, giving an untrusted client our API key isn’t really acceptable either, for reasons I hope are obvious.

Currently we are using an S3 bucket as an intermediate, giving the client a signed PUT URL to upload the video to and then it can make a call to our API which creates the video in api.video and gives it a signed GET URL for hosted upload, to save our API server the load of directly handling video uploads. It works well enough but test users are complaining about how long it takes for a video to upload and process.

Our only other option right now, besides just moving upload functionality to our main API server, is to develop a microservice solely for the purpose of playing middleman between clients and api.video.