Introduction

When you add AI avatars to a product, the hard part is usually not rendering video. It is deciding where authentication lives, how much trust you put in the browser, and which session semantics belong to your backend versus the client. That gets more subtle once the avatar is part of a streaming voice agent or a WebRTC session, because you are dealing with short-lived interactive sessions, media tracks, and browser-origin constraints rather than a simple REST request.

This post walks through the backend-for-frontend pattern for auth in that environment. By the end, you should be able to reason about which credentials stay server-side, how to mint browser-safe session access, and how to structure a frontend that can join realtime avatar sessions without leaking API keys. I will also show where Protoface fits when you want an avatar layer for LiveKit agents or an iframe-based embed with no backend exposure.

Why backend-for-frontend auth matters for streaming AI avatars

In a typical web app, the browser calls your API directly with a user token. For streaming AI avatars and WebRTC, that model is often too loose. A browser session can initiate media transport, negotiate ICE candidates, and keep a realtime connection alive for minutes. If you hand the browser a long-lived platform API key, you have effectively given it the ability to create or modify sessions outside the user’s intent.

The backend-for-frontend, or BFF, pattern solves this by moving privileged operations behind your server. The browser authenticates to your app, your backend validates the user and business rules, and then your backend returns only the minimum data needed to start a specific session. In practice, that often means:

• API keys and service credentials stay in server-side code.

• The browser receives short-lived, narrowly scoped session data.

• Your backend enforces tenancy, rate limits, feature flags, and quota checks.

• Any replayable token is bound to a single session, embed, or conversation.

For realtime avatars, that separation is especially important because the media session itself is usually ephemeral, but the business authorization is not. A user may be allowed to start one support avatar session, but not spawn unlimited sessions or change avatar configuration. Those checks belong in the BFF, not in the frontend.

Separate three different trust boundaries

It helps to distinguish between three layers that are often conflated:

1. Your app auth — who is the end user? This is your normal login/session/JWT layer.

2. Avatar platform auth — who can create avatars, sessions, or inspect usage? This is typically an API key or service token that only your backend uses.

3. Realtime transport auth — who can join a specific media session right now? This is usually a short-lived token, room secret, signed URL, or similar session artifact.

The common mistake is to let the browser hold layer 2. That is almost always too much power. Instead, the browser should receive only layer 3 artifacts, and only after your backend has already decided that the user may join that particular session.

For WebRTC-style sessions, keep in mind that signaling, TURN/ICE negotiation, and media transport are separate concerns from your product’s authorization model. Signaling endpoints should validate session intent. Media transport should be scoped to a session, not a user account. If the avatar platform exposes a REST endpoint to create a session, that call should originate from the backend with service credentials, then the frontend should get a narrow join payload.

Implement the BFF flow for a realtime avatar session

A practical flow looks like this:

1. The user clicks “Start avatar”.

2. The browser calls your backend, not the avatar platform directly.

3. Your backend checks user entitlement, quota, and any project-specific rules.

4. Your backend creates or prepares the avatar session using server-side credentials.

5. Your backend returns only the session data needed for the browser to join or embed the session.

6. The browser connects to the realtime transport and begins the conversation.

The exact shape of the returned payload depends on your stack and the platform, but the principle is the same: the browser gets a session handle, not a platform secret.

Example: backend creates a session with the REST API

When the browser asks for a new session, your server can call the REST API with a bearer key stored in your environment. Keep the request body and response fields aligned with the docs; the point here is the auth flow, not the exact schema.

curl -X POST https://api.protoface.com/sessions \
}'

curl -X POST https://api.protoface.com/sessions \
}'

curl -X POST https://api.protoface.com/sessions \
}'

Your backend should store the returned session identifier or join parameters in memory or your own session store, then send the browser only the minimum required information. If your app uses a signed embed URL or a short-lived token, return that instead of the full platform response. The key idea is that the browser should never see sk_live_... or any equivalent reusable API credential.

Frontend should attach to an ephemeral session, not create authority

The frontend’s job is to render UI, request a session, and join it. It should not decide which avatar can be used, which voice is allowed, or whether a user has exceeded quota. Those decisions are backend policy.

That separation becomes even more important when the UI can be embedded in third-party pages or when a conversation can be resumed. If you need to refresh a session, do it through your backend and require the user to re-authorize if the session has expired. For browser-side code, prefer a small state machine:

• idle — no session yet.

• requesting — frontend asks backend for a session.

• joining — browser receives join data and connects.

• active — media tracks and events are live.

• ended — session closed or expired.

This makes the failure modes easier to reason about. A failed join is not the same as an unauthorized session creation, and a disconnected media track is not the same as a revoked token.

Example: Python SDK call from your backend

If your backend is Python, the SDK is a natural place to centralize avatar and session management. The snippet below is illustrative; check the docs for exact method names and fields.

import os

}

import os

}

import os

}

That pattern lets you keep the API key in your environment or secret manager, while the browser gets only session_id and whatever short-lived join material the platform requires. If you are doing request logging, redact any token-like fields before they hit your logs.

Common gotchas with WebRTC and streaming auth

There are a few places this architecture usually breaks:

• Long-lived bearer tokens in the browser — if the browser can reuse a token for arbitrary sessions, you have not really scoped auth.

• No session expiry — realtime sessions should be time-bound. If they can be resumed indefinitely, treat that as a higher-risk capability.

• Missing origin checks — for browser-initiated flows, validate the origin of the request, especially if you support embedded usage.

• Trusting client-supplied avatar IDs — the frontend can request a preferred avatar, but the backend should enforce whether that avatar belongs to the current tenant and plan.

• Ignoring rate limits — session creation is a business action, not just a transport action. Rate limit by user, org, and IP where appropriate.

For streaming AI systems, another subtlety is that media and model latency are part of the product experience. If your session creation path blocks on expensive work, users perceive the entire flow as slow. A good BFF keeps authorization fast and pushes only the minimum session setup necessary before the browser can connect.

Where Protoface fits: backend-owned session creation and browser-safe embeds

This is the part where Protoface is useful without changing the architecture. The REST API is built for server-side session and avatar management, while customer-managed iframe embeds are designed so you never expose an API key in the browser. That means you can keep the BFF model intact even when the UI is a simple embedded avatar on a marketing page or support portal.

If you are integrating through an iframe, the backend can configure the embed, including per-embed voice, custom instructions, parent-origin allowlists, and rate limits by IP and duration. That is a cleaner fit for third-party websites than shipping credentials to JavaScript. If you are building a voice agent, the LiveKit plugin path is similar in spirit: the agent and avatar synchronization live in backend infrastructure, not in browser code. The relevant quickstarts and examples are linked from the project repository and docs, which is the right place to confirm exact payloads and integration details.

For teams using Python, the SDK gives you the same server-side control model in code, so the browser never needs direct access to the platform key. If you want implementation examples, the main docs are at docs.protoface.com, and the integration repositories under github.com/protoface-ai are useful when you want to see a complete flow rather than isolated API calls.

Conclusion

For realtime avatar APIs and WebRTC sessions, auth should be split along trust boundaries: your app authenticates the user, your backend authorizes the action, and the browser receives only short-lived session material. That is the backend-for-frontend pattern in its most practical form. It reduces key leakage, keeps authorization centralized, and makes session handling easier to reason about when media transport enters the picture.

If you are implementing this now, start by moving all platform credentials into your backend, then add a single “create session” endpoint that returns only the minimum data needed by the frontend. From there, layer on expiry, origin checks, and rate limits. For exact API shapes, SDK usage, and quickstart examples, use the docs at docs.protoface.com.