Roku Developer Program

[joetesta]

Is anyone using token auth with CDN?
Can I have the XML media's streamURL point to an auth program that returns the token embedded link to the player? Will this work with the adaptive bitrates? (ie when the player senses bandwidth change, it would try to get the next stream by hitting the auth program again and asking for the new bitrate and receiving back a token embedded URL.
thank you for any advice,
joe

[RokuJoel]

Unless I'm misunderstanding what you mean by token auth, generally what you mean is something like OAuth, or Oauth2. Essentially, you pass the username and password via SSL to your server, and your server returns a couple of tokens, the first being the Refresh token and the second being the auth token, usually good for a specific length of time like 1 hour. Your device then includes the token in the URL when it connects each time to the server. If the token is not in the URL then your server rejects or ignores the request. So any connection to the server would use the stored token, until it expires, at which point you would use your Refresh Token to get a new auth token. That is one approach.

Another is to have a unique key stored on the device that all requests are signed with. The signature is usually the URL parameters, sorted alphabetically, and signed with the key as an MD5 hash or using SHA256 or SHA128. Each url expires within a few moments after it is used, and a new signature is generated **on the roku** from the locally stored key for each URL request. Again, your server rejects or ignores any non-signed URLs. The signature has to match the content of the URL parameters. You could generate the signing key on your server and return it via SSL when the user enters their username and password, or when the user Links their device to your website.

Most cases though, the key (usually called the developer key) is used for all devices, and would be hard-coded into the application.

- Joel

[joetesta]

thank you Joel. Your first scenario is definitely something I could do.
I was more envisioning that roku would hit the auth program for a new unique token on every media request. Then the token would be sent with the media request to the CDN where it would be verified in the db, and expire in a minute or less, whatever time it takes to bounce them over to the CDN and get validated there.

So here's how i would propose to do it;

in the xml the media would be listed with the various bitrates as per normal.
but each of those URLs is not the actual media, but the token generator program on our server that takes the filename on the end of the URL request as a variable.
It checks the user's deviceToken to make sure the user is valid, generates a token and inserts into db on the server side,
then returns "Location: http://cdn.url/the_media_file&the_token"
then theoretically the roku goes to get the video file there, the CDN takes the_token, runs a request against a program on our side to say "is this token good for this media file?" and depending on the response, serves the media.
then if the roku switches bitrates, the whole process is repeated (new unique token generated for the new media file request).

only people on our app can generate tokens, and only people with tokens can get served the media.
an advantage this way is that we can track every hit in the db via the token generation and subsequent authentication.

will it work? i need to try it tomorrow and find out...

[joetesta]

an update: my test was successful, in that I can make roku think it is getting a stream while it's actually calling the program to generate a token and receiving back the streamURL location with token attached, so I believe this method for authenticating each media request will work.
Now I've got some building to do to actually generate & authenticate real tokens.