Introduction

When you put a realtime AI avatar into an HR screening flow, you are dealing with two separate trust boundaries at once: the agent session itself, and the browser or app that is allowed to open that session. If you skip auth design, you end up with one of two bad outcomes: either the avatar is too easy to abuse, or you make the integration so cumbersome that teams work around it with static credentials in the frontend.

This post shows a practical pattern for securing a realtime avatar session with JWTs and short-lived tokens. By the end, you should be able to design a flow where a backend vends a tightly scoped token, the browser uses it to join only the intended screening session, and the token expires quickly enough to limit replay and leakage.

The security model: separate identity, authorization, and session scope

For HR screening, “who is this applicant?” and “may this client open an avatar session?” are different questions. A good setup keeps them separate:

• Application identity: the candidate authenticated to your product, or at least arrived through a signed invite flow.

• Session authorization: the backend decides whether this user may start a specific screening session.

• Realtime session token: a short-lived credential that only authorizes the minimum action needed, usually joining or creating one avatar session.

This is the point where JWTs help. A JWT is not automatically “more secure” than an opaque token, but it is very useful when you need a verifiable blob containing narrow claims: subject, session ID, expiry, issuer, and optionally tenant or role. The important part is not the format; it is that the token is signed by your backend and expires quickly.

For a realtime avatar, that usually means the backend mints a token after checking business rules, and the frontend presents it only long enough to establish the media session. After the connection is established, the token should be useless.

Design a short-lived token flow

A solid pattern looks like this:

1. The applicant authenticates to your web app.

2. Your backend validates that the applicant is eligible for a screening session.

3. Your backend creates or looks up the avatar session.

4. Your backend issues a JWT with a short expiration, scoped to that one session.

5. The browser uses the token to initialize the realtime connection.

Keep the token lifetime short: often 1-5 minutes is enough for a join flow. If the session is not established before expiry, mint a new token server-side. This makes leaked tokens much less useful and narrows the replay window.

Useful claims usually include:

• sub: the user or candidate identifier

• sid: the avatar or screening session identifier

• iss: your issuer name

• aud: the intended consumer, if you validate audience

• exp: short expiry

• iat: issued-at time

• jti: unique token ID for replay tracking if needed

Two implementation details matter in practice:

• Do not put long-term API keys in the browser. The browser should only see a short-lived session token.

• Bind the token to one session. A token that can open any avatar session is a privilege escalation waiting to happen.

Minting and verifying JWTs correctly

If you already have a backend, JWT issuance is straightforward. The most common mistakes are weak expiration handling, overly broad claims, and trusting client-supplied session IDs without server-side checks.

Here is a minimal Python example that issues a signed token for a screening session. The exact claim names and signing algorithm are up to your app, but the structure is what matters:

import time

return jwt.encode(payload, secret, algorithm="HS256")

import time

return jwt.encode(payload, secret, algorithm="HS256")

import time

return jwt.encode(payload, secret, algorithm="HS256")

On the verifier side, reject anything with the wrong issuer, wrong audience, expired timestamps, or a mismatched session identifier. If you want stronger replay protection, store jti values until expiration and reject duplicates, but that is usually only necessary for high-risk flows.

One subtle point: if the token is only used to bootstrap a realtime connection, the server that verifies it should translate claims into a session-specific capability, not pass the JWT downstream as a general-purpose credential. In other words, verify once, authorize once, then issue the narrowest possible internal session state.

Secure the browser handoff

The browser is the weakest part of the chain, so keep its responsibilities minimal. It should request a session token from your backend and use it immediately. It should not be able to derive the token itself, and it should not receive credentials with broader privileges than the current session.

A few rules that save pain later:

• Fetch the token over HTTPS only.

• Store it in memory, not local storage. If the page refreshes, ask the backend for a new token.

• Use same-site cookies or your existing app session to authenticate the token minting request.

• Validate candidate and session ownership server-side. Never trust a session ID just because the browser sent it.

For HR screening specifically, also think about data retention and access controls around recordings, transcripts, and session metadata. The realtime auth layer only solves access to the session; it does not solve compliance by itself.

Where Protoface fits

This is exactly the kind of integration Protoface is designed to support. The important integration surface here is the REST API at docs.protoface.com: keep your API key on the server, create/manage avatars and sessions there, and have your app mint only short-lived browser-facing credentials for the specific screening flow.

That separation works well whether you are driving the avatar from your own frontend, a voice agent, or a backend workflow. A minimal server-side call to create a session might look like this:

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

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

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

Your app would then pair that session with your own JWT-based authorization layer. The exact request shape depends on the endpoint details in the docs, but the architectural principle stays the same: server-to-server API key usage for management, short-lived token usage for client access.

If you are embedding the avatar in a browser, the same rule applies even more strongly: keep the long-lived secret off the client, and gate the iframe/session with server-issued, time-bound access.

Common failure modes and how to avoid them

The mistakes I see most often are boring but expensive:

• Long-lived browser tokens: convenient at first, painful after the first leak.

• Token reuse across sessions: one candidate’s token should not unlock another candidate’s interview.

• Skipping server-side authorization: if the browser can ask for any session ID, you do not have authorization, only obscurity.

• No expiry on media bootstrap tokens: even a “temporary” token becomes a credential if it never dies.

• Logging secrets: redact JWTs and API keys from application logs and frontend error reporting.

For a realtime system, another practical issue is reconnects. If the media layer drops and the client needs to reconnect, do not reuse a token that has already expired. Instead, treat reconnect as a normal authenticated backend request and mint a fresh token after rechecking that the screening session is still valid.

Finally, if you need to scale this pattern to multiple services, keep the JWT purpose narrow. A session token for an avatar join should not also grant access to candidate records, analytics, or admin endpoints. That kind of scope creep is how auth bugs turn into incidents.

Conclusion

The secure pattern for an HR screening avatar is simple: authenticate the user to your app, authorize the screening on your backend, mint a short-lived JWT for one realtime session, and keep your API keys server-side. That gives you a narrow, auditable trust boundary and avoids putting durable secrets in the browser.

If you are integrating a realtime avatar into a voice agent, web app, or screening workflow, start with the docs at docs.protoface.com, and then wire your auth layer around the smallest possible client token. That is the difference between a demo and something you can actually operate.