Privacy and Retention

Privacy and Retention

What this plugin stores about a person in its own configuration, how long it keeps it, and which administrator action erases it.

Scope. This page covers the plugin's own persisted state and nothing else. Everything a login produces - the Jellyfin username, the account's permissions, the synced avatar - is stored by Jellyfin's own user store, is erased by Jellyfin's own user deletion, and is outside this page. Nothing here is a compliance statement for a deployment; the operator of a Jellyfin server is the controller of its data, and this page exists so they can say what the plugin holds.

The plugin makes no telemetry, update-check or analytics call of any kind. The only external party in the flow is the identity provider the operator chose.

What is persisted, per link

The plugin's unit of stored personal data is the canonical link: one entry per identity, keyed by the stable subject the identity provider issues (sub on OpenID, NameID on SAML), mapping it to a Jellyfin user id. It lives in the plugin configuration XML in the Jellyfin configuration directory.

Three further per-link values ride with it, keyed by the same subject, and each is removed with the link it describes:

Value	What it is	Kept for
The bound issuer	The OpenID issuer the link was made under, so a provider repointed at a different identity provider cannot resolve an old subject onto the old account	The life of the link
The expiry deadline	Present only where the provider names an expiry claim	The life of the link
The last SSO login	One UTC instant, described in full below	The life of the link

The last-SSO-login timestamp

What is stored. One UTC instant per canonical link, keyed by the same stable subject the link itself is keyed by. No username, no claim value, no IP address, and no event history. One entry per link that already exists, overwritten by the next login rather than appended to, so the map's cardinality is the link map's. It is a bounded per-link field, not a log.

Where. The plugin configuration XML, beside the link map itself. It is withheld from the configuration JSON surface in both directions - a configuration read cannot return it and a configuration write cannot forge one - and it does not appear in the administrator configuration export. So it travels through neither the admin page nor an export.

For how long. The life of the link. There is no separate retention period and no expiry of its own, because the entry cannot outlive the link it describes.

How it is erased. By the routes an administrator already has. There is no new control and no separate deletion request path:

• unlinking that account from the provider;
• removing the account's links from the dashboard;
• deleting the provider;
• changing an OpenID provider's discovery endpoint, which drops that provider's links and takes the stamps with them. That is deliberate rather than incidental: a repoint re-identifies the provider, and carrying the login history of subjects whose links were just dropped would retain data about accounts the provider no longer knows, with no administrator route left to erase it.

One caveat, because a reader would otherwise assume the opposite. The stored instant is coarse. A successful login rewrites it only once the stored value has aged past an hour, so it reads as "not later than" rather than as a precise login time. It is accurate to that granularity and never fresher, and it is not a session timeline. The reason is cost rather than privacy: the ordinary repeat login of an established user pays no configuration write at all, and a write-through stamp would put one on the login path, on the file that carries every provider secret envelope and every link map.

What is not persisted

• The email claim, the display name and the role or group claims are read during a login and not stored by the plugin. What the login produces from them - the account, its name, its permissions - is Jellyfin's.
• The client IP address is held in memory only, by the opt-in rate limiter, and is gone on restart. It is not written to the plugin's audit lines.
• Login-flow state - the authorize state, the one-time outcome tokens, the SAML request and replay caches - is in memory, single-use and short-lived.

See also

• Security Model - what each stored value defends against.
• Hardening & Options Reference - the per-option reference, including time-limited access and the configuration export.