Authentication

Understand product authentication, session tokens, JWT claims, API keys, and the authentication flow.

Authentication

Blendlix Call Service uses two authentication layers:

  1. Product authentication for trusted backend-to-service requests.
  2. Session tokens for client WebSocket connections.

Product authentication

Product authentication protects the session token endpoint. The application backend sends product credentials when requesting a call session.

X-BCS-Product-Key-ID: your_key_id
X-BCS-Product-Secret: your_secret

Product credentials must never be stored in browser JavaScript, mobile apps, or public repositories.

API keys

Each registered product receives:

ValuePurpose
Product key IDIdentifies the registered product.
Product secretProves the request is coming from a trusted backend.

The secret should be treated like a password.

Session tokens

After the application backend checks permissions, it calls POST /v1/call/session-token. Blendlix Call Service returns a short-lived JWT.

The client uses this JWT to connect to:

wss://rtc-svc.blendlix.com/v1/ws

JWT claims

The session token includes claims such as:

ClaimMeaning
productProduct or application namespace.
subExternal user ID from the application.
roleRole of the authenticated participant.
context_typeApplication-defined call context type.
context_idApplication-defined call context ID.
allowed_peer_rolesReceiver roles this token is allowed to invite.
permissionsAllowed call and WebRTC actions.
expToken expiration time.
jtiUnique token ID used for replay protection.

Authentication flow

1. Client asks application backend for call session.
2. Application backend authenticates the user.
3. Application backend checks call permissions.
4. Application backend calls Blendlix Call Service with product credentials.
5. Blendlix Call Service returns a session token.
6. Client connects to WebSocket using the session token.
7. Blendlix Call Service validates the token before accepting the connection.

Browser WebSocket authentication

Browsers cannot send custom Authorization headers during a native WebSocket handshake. Use the jwt subprotocol:

const ws = new WebSocket(wsUrl, ['jwt', sessionToken])

Server-side WebSocket clients may use:

Authorization: Bearer <session_token>