Secret Handling

When integrating Room, protect application secrets and short-lived connection credentials. They must not appear in device firmware, client source code, logs, or support screenshots.

Credentials to Protect

Credential	What it is	Allowed location	Should not appear in
app_secret	Application-level server secret used to call the Token service.	Your application server.	Device firmware, client source, frontend pages, public repos, logs.
token	Short-lived TiRTC-X room credential.	Temporarily on the device.	Long-term cache, full logs, chats, support screenshots.
peer_id	TiRTC connection target identifier.	Temporarily on the device.	Unredacted logs or public examples.

Do Not

• Put app_secret into device firmware or sample projects.
• Let devices call POST /v1/token/room directly.
• Log the full Authorization, token, or peer_id.
• Cache tokens for a long time or reuse expired credentials across joins.

Recommended Practices

• Issue credentials only from your application server and deliver them to devices through a secure channel.
• Release tokens soon after use, and request a new one after expiration or failure.
• Log only diagnostic fields such as room_id, device_id, session_id, and error code.
• Redact sensitive values before sharing troubleshooting material.

If a Secret Was Leaked

1. Stop using the leaked secret immediately.
2. Confirm the leak scope, including repositories, logs, chat history, and screenshots.
3. Create or rotate application secrets.
4. Remove historical copies and check whether abnormal token issuance or room joins occurred.