Jitsi authentication session expired: what to do

Short answer

Use the meeting's Login action to renew your session when Jitsi asks you to authenticate again. If you were disconnected, return through the organizer's trusted invitation or application. Login expiry is separate from meet.jit.si's 95-minute room limit. Private integrations must also handle their own token lifetime and renewal. [S1][S2][S4][S5]

Losing the end of a chat message instead? That is a separate truncation problem, even though both symptoms appeared in one upstream report.

Recognize the warning

The reviewed Jitsi client includes this message: “Your authentication session has expired. You need to login again to continue the meeting.” Its web token-expiry handler can display a Login action and run a configured authentication flow. [S2]

That message is a useful diagnostic clue. It does not, by itself, identify a camera problem, a failed media port, an expired room password or a room that reached its duration limit. Use the login prompt guide when the message asks for a moderator, lobby admission or a room password instead.

If you are in the meeting now

Recommended recovery sequence:

  1. Use the meeting’s Login action. Complete sign-in with the legitimate provider or organization used for that meeting. On 28 September 2026, a Jitsi maintainer recommended this action for the reported expiry, and the reporter confirmed it restored access. This is evidence for that case, not a guarantee for every deployment. [S1]
  2. Allow the normal flow to complete. The reviewed client supports different renewal paths, including an inline popup or a confirmed redirect. Expect that the flow may interrupt your participation. [S2]
  3. If you disconnected, return through the trusted invitation. For an integrated product, re-enter through that application so it can authorize you again. Avoid relying on a copied token-bearing link whose lifetime may have passed. [S5][S6]
  4. Check that you are back in the intended meeting. Verify the same server and invitation, and confirm other participants can hear and see you before continuing.

If login returns you to a lobby or a room-password prompt, follow that separate access step. Authentication does not automatically replace the organizer’s admission policy. See moderator and password prompts.

Situation What it concerns Next step
The call asks you to authenticate again Login/session renewal Use the legitimate Login flow. [S1][S2]
A meet.jit.si room reaches the announced 95-minute boundary Public-service room duration Follow the time-limit guide; login renewal does not extend that policy. [S4]
A meeting inside another website closes near five minutes Possibly the deployment’s embedding restriction Compare the message and server with five-minute cutoff diagnostics.

Timing alone does not identify which case occurred. The September report described expiry at roughly an hour; it does not establish a universal one-hour Jitsi logout rule. [S1]

Why starting a public meeting can require sign-in

Jitsi announced account-based room creation on meet.jit.si in August 2023. A person creating a room and a guest waiting to join can therefore face different access prompts. The available identity providers and exact flow remain controlled by the service. A company-hosted Jitsi deployment can use another policy. [S3]

Use the providers actually offered by the meeting service. Do not assume you need to create a separate Jitsi account to resolve a session warning. [S3]

For private-server and application owners

The reviewed web middleware handles a connection-token-expired event. Where token authentication and an authentication URL are configured, it offers a renewal action; the inline path obtains a new token and asks the connection to refresh it. This describes that source version’s behavior, not proof that your integration has the same renewal flow. [S2]

Recommended investigation:

  • Identify the deployed client build, authentication mode and application entry point. Preserve the running-version inventory.
  • Check token timestamps and issuer-side renewal behavior privately. JWT exp is an expiration timestamp; changing the encoded payload does not produce a valid replacement signature. Verify through your authorized backend and server policy. [S5]
  • Keep application login, issued meeting token, room authorization and room lifetime as separate checks. The JWT setup guide and JWT diagnostics explain the self-hosted paths. [S5][S6]
  • Test the intended expiry/renewal path in a disposable environment with the same client and sign-in topology. A successful initial join is not a completed renewal test.
  • Confirm whether renewal succeeds, fails, redirects or requires rejoining. Record those outcomes separately from bidirectional audio/video after recovery.

Docker and Debian/Ubuntu operators should inspect their actual installed policy and generated configuration. This warning alone is not a reason to disable authentication, allow empty tokens or make signed tokens indefinite. Use the version-specific instructions for your installation. [S5][S6]

If you still cannot get back in

Use the exact visible message to choose the next path:

For support, collect the client version, server domain, exact error text and approximate time. Keep passwords, JWTs, cookies and private room links out of public reports. A sanitized description is enough to start an investigation.

Open questions and maintenance

Reviewed 24 October 2026. The source review uses Jitsi Meet 11248 commit f765042. We have not reproduced public-service login expiry or measured its current token lifetime. The report and maintainer response establish one recovery case, not a universal timing contract. [S1][S2]

Recheck after client, identity-provider or deployment changes. A successful sign-in, a renewed connection and a working meeting are distinct results; verify each one in the affected environment.

Sources

Written by the Jitsi Help engineering team

Jitsi infrastructure engineers who deploy and run Jitsi Meet servers in production. Last updated . How we write our guides

Stuck on something this page does not cover? Ask a question below. Jitsi Help engineers read every one.

Did this fix it?

Something on this page is outdated or wrong?

Collect debug info

These commands gather what an engineer needs to diagnose a Jitsi server. Copy them, run them, and keep the output.

Terminal
# Run on the server, from your docker-jitsi-meet folder

# 1. Every service should be "running" (or "healthy")
docker compose ps

# 2. Which images and release tags are running
docker compose images

# 3. Recent logs from the core services
docker compose logs --tail=200 web prosody jicofo jvb

# 4. The settings most fixes depend on
grep -E '^(PUBLIC_URL|JVB_ADVERTISE_IPS|ENABLE_LETSENCRYPT|ENABLE_AUTH|AUTH_TYPE)=' .env

# 5. Is anything listening for media on UDP 10000?
sudo ss -ulnp | grep 10000

Installed with the Debian packages instead of Docker? Read the service logs with:

Terminal
sudo journalctl -u prosody -u jicofo -u jitsi-videobridge2 --since "1 hour ago"

Remove passwords, secrets and tokens before you share any output.

Send the output to an engineer

Frequently asked questions

What should I do when Jitsi says my authentication session expired?

Use the Login action shown by the meeting and complete the legitimate sign-in flow. If the call disconnected, reopen the organizer's trusted invitation or enter through the original application. Renewal can involve a redirect or popup and is not a guarantee of uninterrupted media.

Is an expired login the same as the 95-minute Jitsi limit?

No. Login expiry concerns the authenticated session. The announced meet.jit.si duration policy limits the meeting itself. Renewing a login does not extend that room-duration policy.

Does Jitsi always log people out after one hour?

Do not assume a universal one-hour timeout. A September 2026 report described expiry after roughly an hour on meet.jit.si, but that report does not establish a fixed duration for every service, account or client.

Will the room password renew my login?

A room password and your authenticated session are separate. Use the sign-in action for session renewal and ask the organizer for a room password only when the meeting specifically requests one.

What should a private Jitsi integration check?

Check its actual token-expiry and renewal flow, server-side validation and clock handling. A fresh token must come from the authorized application. Client-side decoding or editing a token does not validate it or extend a signed token's lifetime.

Discussion

    Stuck, or would rather not do this by hand?

    Deploy it in one click

    A private Jitsi server in your own AWS account with SSL, your domain and optional recording, transcription and JWT. Free 15 minute trial.

    Start free trial

    Talk to a Jitsi engineer

    Setup, fixes, branding, recording, scaling. Tell us what is happening and we reply with a plan and a quote.

    Get expert help

    Related

    Recently updated