Login sequence

When connecting to the IXNX server you might be requested to log in to be able to use its services.

Depending upon its settings the IXNX server may request you to either log in using digest authentication or present your REST authentication token as a proof of earlier successful authentication. Which one of these two methods to use depends on how your system is designed.

Using digest authentication the server sends a nonce (random value) to the client. The client then calculates an MD5 hash sum of that random value combined with the username and password and sends that hash sum back. By avoiding sending the actual password the method is more secure than basic authentication. Most SIP registrars use digest authentication to allow access.

For a detailed description of the digest authentication sequence read here.

Using REST authentication someone else performs the authentication of the user. As a proof of successful authentication the user receives a token (an encrypted string) that she can give to anyone else to prove someone has authenticated her identity.

For a detailed description of the REST authentication sequence read here.

What kind of authentication is required depends on the Authentication mode setting of the IXNX server. (SIP > WebRTC > Client templates)

The IXNX server itself does not maintain a list of allowed users but use the help of other servers to authenticate users.

No authentication is required for local WebRTC calls. SIP services might however still require digest authentication of the user.

Clients connected to the same IXNX server can call each other without need to log in. But if a SIP address is specified as wrtc.addressName the SIP registrar managing that account's domain may request a digest authentication of the user. If the SIP registrar sends an authentication request it will be forwarded to the web client and your code must be able to handle it.

User authorisation is carried out by a SIP registrar using digest authentication. If SIP registrar rejects user no calls are allowed - not even local WebRTC calls. You specify which SIP registrar(s) are allowed to perform authorisation in IXNX settings and only users successfully registering on those servers are allowed to access IXNX services.

NOTE: The built-in as well as any remote SIP registrar can be used, it should be configured to request digest authentication of users.

Authentication is performed by third party who gives client a temporary REST authentication token as proof of succeeded authentication. Clients lacking token or having wrong token cannot be used. The party issuing the REST token and the IXNX server share a secret phrase to be able to encrypt/decrypt/verify tokens.