How to Secure Gemini Live Apps with Ephemeral Tokens

A Gemini Live app can connect directly from a browser or mobile device, but putting a long-lived API key in that client exposes a credential that can be extracted. Google's new ephemeral-token flow gives Live API developers a different path: keep the real API key on the backend, issue a short-lived token, and let the client use that token for its WebSocket session.

Why a Gemini Live app should not expose its API key

A browser or mobile application cannot keep a secret that it must use directly. If a Gemini API key is embedded in JavaScript, an Android package, or another client application, a user can potentially extract it and use it outside your app. That can turn a legitimate application credential into someone else's source of API usage and billing.

The safer client-to-server pattern is to authenticate the user with your own backend first. Your backend keeps the Gemini credential private, creates a short-lived ephemeral token through Google's token-provisioning service, and sends only that token to the client. The client then opens its Live API connection with the temporary credential instead of receiving your long-lived API key.

What an ephemeral token actually changes

An ephemeral token is a short-lived authentication token designed specifically for Gemini Live API connections made from client applications. It can still be extracted from the browser or mobile app, so it is not a secret in the same sense as a backend API key. The security improvement comes from its limited lifetime, optional restrictions, and limited session use.

Google's current defaults give a newly created token one minute to start a new Live API session and 30 minutes before the token expires. The token can also be configured for a single use. That does not make a compromised client automatically safe, but it sharply reduces the useful lifetime of a stolen credential compared with putting a persistent API key in the application.

Build the token endpoint on your backend first

Start by creating a small authenticated backend endpoint that your web or mobile application can call when it needs a Live API session. The backend needs access to your Gemini API credential, while the client must never receive that credential directly. Your backend should also authenticate the requesting user before issuing a token, because an ephemeral token is only as protected as the endpoint that creates it.

With the Google GenAI SDK installed on the server, the token request can be kept deliberately small. The important settings are the number of allowed uses and the expiration times. A one-use token is a useful starting point for an application where each token is created for one new session.

import datetime
from google import genai

now = datetime.datetime.now(
tz=datetime.timezone.utc
)

client = genai.Client()

token = client.auth_tokens.create(
config={
"uses": 1,
"expire_time": now + datetime.timedelta(minutes=30),
"new_session_expire_time":
now + datetime.timedelta(minutes=1),
}
)

print(token.name)

The value returned as token.name is what your backend passes to the authenticated client. Do not log it unnecessarily, store it as a permanent credential, or return your server's actual Gemini API key alongside it.

Restrict the token to the Live session you expect

A stronger configuration also locks the token to a particular model and session configuration. This matters when the client should be allowed to open a Live session but should not be able to change important server-selected settings.

token = client.auth_tokens.create(
config={
"uses": 1,
"live_connect_constraints": {
"model": "gemini-3.8-live",
"config": {
"session_resumption": {},
"response_modalities": ["AUDIO"]
}
}
}
)

This constraint makes the token more specific to the application you are building. Instead of handing the browser a general credential and trusting the client to select the intended configuration, the backend can define the model and important Live API settings when it provisions the token.

Connect the browser to Gemini without the real key

Once the backend has returned the ephemeral token, the client can use that token as the credential for its Live API connection. The important distinction is that the client receives a temporary credential rather than the backend's long-lived Gemini key.

import { GoogleGenAI, Modality } from "@google/genai";

const ai = new GoogleGenAI({
apiKey: token
});

const session = await ai.live.connect({
model: "gemini-3.8-live",
config: {
responseModalities: [Modality.AUDIO]
}
});

The client can now establish the real-time connection while the permanent credential remains on your server. Gemini Live uses a persistent WebSocket connection for streaming interaction, so this architecture avoids forcing your backend to proxy every audio packet simply to keep the API key private.

Keep token lifetime and session lifetime separate

One detail is easy to misunderstand: token expiration and Live session duration are not the same thing. The token controls how long the credential can be used, while the Live API has its own connection and session-management behavior. A token can therefore be valid for a defined period without making every Live session automatically last that long.

Google's documentation also supports session resumption. With the appropriate configuration, an application can reconnect to an existing session rather than treating every WebSocket interruption as a completely new conversation. This becomes particularly useful for voice applications where network interruptions should not force the user to start over.

Do not treat an ephemeral token as a complete security system

The temporary credential solves one specific problem: reducing the exposure created when a client needs direct access to the Live API. It does not authenticate your users, stop someone from abusing your application, or protect your backend from unauthorized token requests.

Your token endpoint should therefore enforce your normal application authentication and authorization. Add rate limits, reject requests from users who should not have access to the feature, keep the server-side Gemini credential out of source control, and avoid unnecessarily long token lifetimes. If your application has different capabilities for different users, issue constrained tokens instead of giving every client the same configuration.

When to use ephemeral tokens instead of a backend proxy

Ephemeral tokens make the most sense when a browser or mobile application needs a direct, low-latency Gemini Live connection. The client can stream real-time data directly to Gemini while your backend remains responsible for authentication and token provisioning.

A backend-mediated architecture can still make sense when your application needs to inspect, transform, store, or authorize the real-time traffic before it reaches Gemini. The important point is not to force every application into one architecture. Use direct Live connections when their latency and simplicity matter, and keep sensitive control logic on your server either way.

Test the failure cases before shipping

Do not stop after confirming that the first WebSocket connection works. Try using an expired token, requesting more than its permitted number of sessions, changing a server-constrained setting, and calling the token endpoint without valid user authentication. Each case should fail cleanly without revealing your permanent Gemini credential.

Also test what happens when the Live connection drops and the application needs to reconnect. Session resumption can help preserve continuity, but your client still needs to handle token expiration and connection failures deliberately. A secure implementation is one where both the successful path and the rejected paths behave predictably.

The practical rule is straightforward: keep the long-lived Gemini credential on the backend, authenticate the user before issuing access, make each ephemeral token short-lived and narrowly constrained, and let the client use that temporary credential for its Live connection. That gives a browser or mobile app the direct real-time access it needs without turning your permanent API key into part of the application bundle.