API authentication tokens and request identity
An authentication token supplies request evidence associated with an accepted login or credential, while user labels and device identifiers do not authenticate by themselves.
An authentication token is credential evidence that a client supplies with later requests. The server evaluates that evidence under its authentication and session rules.
For Emby user authentication, the documented login result includes an AccessToken. Subsequent requests send it in the X-Emby-Token header.
A user ID is a claim, not the login proof
An app can describe its client, device and user identity in request context. Those labels help the server interpret the request, but naming a user does not establish permission to act as that user.
Emby's authentication documentation requires authentication even when the public user's HasPassword field is false. That field affects the login presentation; it does not turn the user ID into credential evidence.
An original header fragment uses a placeholder:
X-Emby-Token: EXAMPLE_USER_TOKEN
The value is not a real credential and no request is made.
The token has a lifecycle
| State | What it means for a later request |
|---|---|
| Login succeeds and returns a token | The client has the documented credential result |
| Token is supplied | The server still evaluates its validity and applicable identity |
| Token is revoked or otherwise no longer accepted | Later authentication can fail |
| Client deletes its local copy | That client no longer has the stored value; server state is a separate operation |
Emby's documented logout operation revokes the user token. The documentation also describes preserving a token when an app closes without explicit logout. That is different from inventing a universal short expiration interval.
Do not assume every token is a JWT or can be interpreted locally from its characters. Its format and validity belong to the server's contract.
A bearer value must stay within its intended use
A credential usable by possession should be handled as a secret. HTTPS protects the transport leg, while local storage, logs and request construction affect other exposure paths.
A rejected token does not automatically mean the supplied user has been deleted. It can reflect token state or another authentication condition. A valid token also does not grant every possible operation: authorization remains a distinct check.
API keys describe Emby's documented static integration arrangement outside a particular user's login context.
See Also
- API keys for server integrations
- Media server authentication and credential evidence
- Login sessions, tokens and revocation