Auth with nginx-rtmp

idi527

I’m playing around with nginx-rtmp module (here’s a more active fork) and I’m wondering what is the correct way of restricting access to it?

I imagined a flow like this:

a user connects to a socket (phoenix) with a token
Phoenix.Token verifies the user’s id
user is fetched from the database and assigned to the socket
some time later the user can join a channel like user:#{user_id} and if user_id is the same as user.id stored in assigns, this user becomes the broadcaster for this channel and receives a link to where to push his/her rtmp stream.
at this point I start having troubles, how would I verify on nginx side that the stream coming to it is actually from the broadcaster and not some cracked cctv? how would I also forbid any “naughty” rtmp stream to an url that has not been received from user:#{user_id} channel?

I was thinking maybe jwt but I am not sure since I haven’t had any experience with them.

I guess what I am asking is, how something like this generally works?

Should I keep all the rtmp links that have been sent from the channel in some kind of registry and redirect the first rtmp push to nginx-rtmp through this registry which would put an “authorisation” header in the request, so that nginx-rtmp would then check it?

3 comments

#nginx #rtmp

0 12428 3

2017-04-26 03:44:00 UTC

First Post!

Show Best Posts
Show All (oldest first)
Show All (newest first)

idi527

There is an example in readme

# The following notifications receive all
# the session variables as well as
# particular call arguments in HTTP POST
# request

# Make HTTP request & use HTTP retcode
# to decide whether to allow publishing
# from this connection or not
on_publish http://localhost:8080/publish;

# Same with playing
on_play http://localhost:8080/play;

# Publish/play end (repeats on disconnect)
on_done http://localhost:8080/done;

# All above mentioned notifications receive
# standard connect() arguments as well as
# play/publish ones. If any arguments are sent
# with GET-style syntax to play & publish
# these are also included.
# Example URL:
#   rtmp://localhost/myapp/mystream?a=b&c=d

I wonder if that can help me …

Post #1

Most Liked

tcbyrd

The general approach for securing RTMP is to use Stream Keys that are unique to the user account. This works basically the same as an API token, meaning if the key is present in the RTMP URL it will accept the stream. It also means you should typically give the user an option to refresh the token if they feel it’s been compromised for some reason.

Depending on the use case and audience, this is usually the better option than trying to tie it directly to a logged in user. For a lot of broadcasters, it’s common for your RTMP feed to come from external streaming equipment such as a Cerevo LiveShell, which may not even have an HTTP client. JWT usually implements with a timeout as well, which will refresh the token and could interrupt the stream.

You may find this article on implementing Stream Keys with Django helpful.

Post #3