Wowza Community

Fastly HMAC authentication for playback not working


At the moment I am trying to configure token authentication for playback from the Fastly CDN. I used the python example supplied by Wowza. The stream id is added, the expiration is added, but we keep on getting 403 Forbidden responses.

Steps to reproduce:

  • Create a Fastly CDN Streaming target for a livestream

  • Enable authentication and get the shared secret

  • Start the livestream

  • Start livestreaming from OBS

  • Create a HMAC key using the python example

  • Attempt to connect to the Fastly streaming target url with the HMAC attached to the url as specified here (bottom of the page).

  • Get a 403 Forbidden response

Are there specific details about the HMAC token that might solve our issue?

Thanks in advance!


I see my hyperlinks didn’t work in the text.

Python example:

Fastly HMAC documentation example (bottom of the page):

Hello Thomas,

I would suggest opening a support ticket so we can review your specific details in your script and the account. Aside from what is already in the resources you have referenced, it would need a review.


Full disclosure, I have not tested the Fastly HMAC auth, but I have tested others in the Wowza ecosystem.

Double checking here, you mean the python example from over here - ?

Have you tried this in curl? Does it work?


I also have this problem.

I also tried to take a signature from wowza cloud ui. Advanced -> Stream Targets -> - > Security Tab. “Generate Query Parameters” button. The result is same. I get 403 error.

I found mistake in python code. Line 103 contain that code:

return'hdnts=%shmac=%s'% (new_token, token_hmac). 

I think it need “~” symbol before “hmac=”.

Adding this character does not solve problem.

Thanks for letting us know @Anton Globa To let you know we are working on this and will post a resolution soon.

I tried it with the ~ symbol as well, but that did not solve the issue unfortunately.

Curl does not seem to make a difference.

I still get the 403 forbidden response.

So it sounds like we have two issues going on here, one is with the query parameter generator and the other is with the example code. I’ll see if I can help dig into this today. I know the team was focused on getting a release out the door. Thank you for your patience!

Can you help me understand what you are setting your token lifetime (in seconds) and start time (UTC seconds, or now) to? You might be getting a 403 because of that.

Within the 10 minute window yours produces a 403?

As an FYI, this was moved to a support ticket by @Thomas B. Please respond to your support ticket so we can get a quick recap out here for folks in the future. Thanks!

@Anton Globa if you are still experiencing an issue with the Generate Query Parameters, please open a support ticket. I’m not able to reproduce this.

Also, please make sure you are using the Generate Query Parameters button on the stream you are intending to use the query parameters on. These values are not interchangable across streams.

In python generator i use 30000 for lifetime param.

In Wowza Cloud Web UI “Generate Query Param”: “Append the query parameters to all playback URLs for testing. Parameters expire 10 minutes after they’re created.” 10 minutes

Hi all,

I figured out (together with the support ticket ofc) what the problem was. When generating the tokens using the command line python implementation, I kept on using the wowza API stream id where I should have used the fastly stream id (I guess? still vague). Anyways, this bit solved it:

-u, --stream_id STREAMID(required) The stream ID from the Wowza Streaming Cloud playback URL, which is the playback_url of the Wowza CDN on Fastly stream target. Using this example, https://[subdomain][stream_id]/[stream_name]/hls/live/playlist.m3u8, the value would be [stream_id].

I was using the id from the[LIVESTREAM_ID] link that you use to reach the Wowza API.

Hopefully this will help others and keep people from being stuck on the “not-reading-the-manual-clear-enough” mistake that I made. When I saw the python instructions I blindly assumed the stream_id would have to be the one being used in the wowza API.



Thanks for circling back and following up here Thomas! I’ll work with the documentation team to see if we can make that a little easier (or more obvious) to understand.

I also solved my problem, but it turned out to be different.

I checked the page with the player in another browser (Firefox). The page opened without problems.

The player did not work only in the chrome browser.

As I found out later due to the fact that the browser did not send cookies to the second request for chunklist.m3u8.

To solve the problem with the Chrome browser, I turned on authorization token only for the playlist

Glad to hear it! Thanks for coming back to update your post.