10

I'm intending to run my own TURN service for a WebRTC app with coturn - https://code.google.com/p/coturn/. The manual says this about authentication and credentials:

   ...

   -a, --lt-cred-mech
          Use long-term credentials mechanism (this one you need for WebRTC usage).  This option can be used with
          either flat file user database or PostgreSQL DB or MySQL DB or MongoDB or Redis for user keys storage.

   ...

This client code example also suggests that credentials are required for TURN:

// use google's ice servers
var iceServers = [
  { url: 'stun:stun.l.google.com:19302' }
  // { url: 'turn:192.158.29.39:3478?transport=udp',
  //   credential: 'JZEOEt2V3Qb0y27GRntt2u2PAYA=',
  //  username: '28224511:1379330808'
  // },
  // { url: 'turn:192.158.29.39:3478?transport=tcp',
  //   credential: 'JZEOEt2V3Qb0y27GRntt2u2PAYA=',
  //   username: '28224511:1379330808'
  // }
];
  • Are they always required? (Coturn can be run without any auth mechanism, but it isn't clear from the man page whether it's strictly required for WebRTC to work)
  • If required, can I just create one set of credentials and use that for all clients? (The client code example is obviously just for demonstration, but it seems to suggest that you might hard-code the credentials into the clientside code. If this is not possible/recommendable, what would be the recommended way of passing out appropriate credentials to the clientside code?)
Gus Hogg-Blake
  • 2,393
  • 2
  • 21
  • 31

1 Answers1

17

After testing it seems that passing credentials is required for clientside code to work (you get an error in the console otherwise).

Leaving the "no-auth" option enabled in Coturn (or leaving both lt-cred-mech and st-cred-mech commented) but still passing credentials in the application JS also doesn't work, as the TURN messages are somehow signed using the password credential. Maybe Coturn isn't expecting the clients to send authentication details if it's running in no-auth mode, so it doesn't know how to interpret the messages.

Solution

Turning on lt-cred-mech and hard-coding the username and password into both the Coturn config file, and the JS for the application, seems to work. There are commented out "static user" entries in the Coturn configuration file - use the plain password format as opposed to key format.

Coturn config (this is the entire config file I got it working with):

fingerprint
lt-cred-mech
#single static user details for long-term authentication:
user=username1:password1
#your domain here:
realm=mydomain.com

ICE server list from web app JS:

var iceServers = [
    {
         url: 'turn:123.234.123.23:3478', //your TURN server address here
         credential: 'password1', //actual hardcoded value
         username: 'username1' //actual hardcoded value
    }
];

Obviously this offers no actual security for the TURN server, as the credentials are visible to anyone (so anyone can use up bandwidth and processor time using it as a relay).

In summary:

  • yes, long-term authentication is required for WebRTC to use TURN.
  • yes, it seems that you can just hard-code a single set of credentials for everyone to use -- coturn isn't bothered that two clients get allocations simultaneously with the same credentials.
  • one possible solution for proper security with minimal hassle would be a TURN REST API, which Coturn supports.
Gus Hogg-Blake
  • 2,393
  • 2
  • 21
  • 31
  • if you want to offer TURN and STUN service, you would probably need to add domain trusted certificate and private key to the configuration file using `cert` and `pkey` properties. – logoff Feb 18 '15 at 14:14
  • TURN REST API link above is broken, [here](https://github.com/RTCEngine/coturn-cluster/blob/master/turn_rest_api.py) is a link to github for it. – Julio Spinelli Jul 23 '21 at 21:26