Application server

Your application server must communicate with your OpenVidu deployment to create Sessions and Connections before your clients can connect to a video call. This is the way that OpenVidu guarantees the security of your Sessions. Visit section Developing your video app to learn about these basic concepts.

There are Java and Node SDKs available to integrate OpenVidu into your application server, but of course you can consume OpenVidu REST API directly from any backend framework.

You will need your OpenVidu deployment URL and your OpenVidu secret to reach your OpenVidu deployment from your application server. In all of the examples below, these are represented by variables OPENVIDU_URL and OPENVIDU_SECRET.

1. Initialize a Session 🔗

You must first initialize a Session in OpenVidu. Participants connected to the same Session are able to send and receive Streams between them (see Basic Concepts).

OpenVidu openvidu = new OpenVidu(OPENVIDU_URL, OPENVIDU_SECRET);
SessionProperties properties = new SessionProperties.Builder().build();
Session session = openVidu.createSession(properties);

See JavaDoc

2. Create a Connection 🔗

You must create Connections for a specific Session to allow participants to connect to it. Each participant will take one Connection, using its Token to connect (see Basic Concepts).

ConnectionProperties connectionProperties = new ConnectionProperties.Builder()
Connection connection = session.createConnection(connectionProperties);
String token = connection.getToken(); // Send this string to the client side

See JavaDoc

Server application samples 🔗




Coming soon...


Coming soon...

These are all basic server applications that provide a good starting point for your backend integration of OpenVidu.

  • All of them provide the same 2 endpoints to perform the 2 basic operations: initializing Sessions and creating Connections.
  • All of them are interchangeable: an application that consumes these 2 endpoints will work with any of the sample server applications.
  • All of them are configured to allow CORS from any origin. In production environments your application server may be configured to allow only calls from specific client origins.
  • None of them offer any kind of user control. In production environments generally your application server should know who is trying to initialize Sessions and create Connections. User control is a topic outside the scope of OpenVidu, and will depend on the chosen technology.

REST endpoints 🔗

The two endpoints offered by all server application samples are documented below. Note that by default all applications listen on https://localhost:5000 when serving them using the official instructions:

1. Initialize a Session
URL https://localhost:5000/api/sessions
REQUEST BODY Same request body as the REST API operation POST /openvidu/api/sessions
200 OK RETURN VALUE A string with the Session identifier.
For example: "ses_JM9v0nfD1l"
2. Create a Connection
URL https://localhost:5000/api/sessions/SESSION_ID/connections
REQUEST BODY Same request body as the REST API operation POST /openvidu/api/sessions/<SESSION_ID>/connection
200 OK RETURN VALUE A string with the Connection's token.
For example: "wss://localhost:4443?sessionId=ses_JM9v0nfD1l&token=tok_MIYGGzuDQb8Xf1Qd"

User Authentication 🔗

Authentication is a common topic in web applications. Let's briefly explain here the different alternatives to include it in your OpenVidu server application.

If your app has already implemented user authentication, you can simply check the user's credentials in your server application and use them to control who is able to initialize Session and Connection objects.

However, if your server application does not have any user authentication yet and you are thinking about adding it, there are different strategies you can follow. The most common are:

  1. Basic authentication
  2. Cookie-based authentication
  3. Token-based authentication
  4. OAuth 2.0
  5. OpenID Connect
  6. SAML

Basic authentication 🔗

This is a simple authentication method that uses a username and a password. The client application will send the credentials encoded with Base64 in the Authorization header with Basic prefix as stated below:

Authorization: 'Basic' + encodedUsingBase64('username':'password')

This credentials will be validated by the server, which stores the usernames and passwords in a database.

This is one of the most common ways to implement user authentication in web applications. The server application will create a session ID and store it (statefully) in a cookie and return it to the client-side via a cookie header. This cookie will be sent in every subsequent request to the server, which will be able to identify the user by reading the cookie. On logout the cookie will be deleted from both client cookie store and server.

Note that this is a stateful authentication method, so the server will need to store the session ID in a database or in-memory cache. This is not a problem for small applications, but it can be a problem for large applications with many users.

Token-based authentication 🔗

This is a more modern way to implement user authentication in web applications. It is gaining popularity because of the SPA (Single Page Application) trend and stateless REST APIs applications.

There are many different ways to implement token-based authentication. The most popular is the JWT (JSON Web Token) authentication. Receiving the credentials from the client, the server will validate them and return a signed JWT token which contains user information.

Contrary to the Cookie-based method, this token will never be stored in the server side. The client stores the token in the browser's local storage and sends it in every request to the server. The server will simply validate the token, granting access to the user.

Note that this authentication method is stateless. This means that the server will not store any information about the user. This is a good thing because it will scale better and will be more secure. However, it also means that the server will not be able to revoke the token. If the token is stolen, the only way to revoke it is to change the secret key used to sign the token.

OAuth 2.0 🔗

OAuth 2.0 is an authorization framework that enables applications to obtain limited access to user accounts on an HTTP service, such as Facebook, Google, GitHub, Apple, etc. It works by delegating user authentication to the service that hosts the user account, and authorizing third-party applications to access the user account. OAuth 2.0 provides authorization flows for web, mobile and desktop applications.

Note that OAuth 2.0 is an authorization protocol that delegates user authentication to the service that hosts the user account. Your server application will be communicating with these third-party services to provide authentication.

OpenID Connect 🔗

OpenID Connect is an authentication layer on top of OAuth 2.0. It is a simple identity layer on top of the OAuth 2.0 protocol, which allows Clients to verify the identity of the End-User based on the authentication performed by an Authorization Server, as well as to obtain basic profile information about the End-User in an interoperable and REST-like manner.

Note that OpenID Connect, just as OAuth 2.0, is an authorization protocol that delegates user authentication to the service that hosts the user account. Your server application will be communicating with these third-party services to provide authentication.


SAML (Security Assertion Markup Language) uses the same Identity provider used by OpenID Connect and OAuth 2.0, but it is XML-based. SAML is an open standard for exchanging authentication and authorization data between security domains and it is maintained by the Organization for the Advancement of Structured Information Standards (OASIS).

Some SAML providers that can be found in the industry are: