Troubleshooting

Troubleshooting

"Invalid or expired state" after an OpenID login

The login-state entry lives for about 15 minutes, long enough for a provider-side MFA or consent step. If the round-trip takes longer than that, the callback lands on a different plugin instance, or the callback comes in under a different provider than the one that started the login, retry the sign-in. States are per-instance, in-memory, and provider-bound.

The login is also bound to the browser that started it by a short-lived __Host- cookie (see Login browser binding), so the same message appears when the callback is opened in a different browser, after clearing cookies mid-flow, or over plain http:// — the Secure binding cookie is only stored over HTTPS, so on an HTTP-only deployment every login fails this way. Serve SSO over HTTPS (a TLS-terminating reverse proxy is fine) and complete the login in the browser that started it. Two logins running at once in the same browser share the one cookie; the later one wins and the earlier tab must be retried.

OpenID login fails with "Identity token validation failed" or "invalid_signature"

The id_token returned by the provider is validated fail-closed — signature, issuer, audience, expiry (see Security Model). A refused login usually means one of:

• the provider signs the id_token with a symmetric algorithm (HS256) or leaves it unsigned — switch the client's id_token signing algorithm to RS256 (some Auth0 and Keycloak client templates default to HS256); EdDSA/Ed25519 is not supported;
• clock drift beyond the skew allowance between the Jellyfin host and the IdP — keep both on NTP;
• the token's issuer differs from the discovery issuer (some templated or multi-tenant setups) — set DoNotValidateIssuerName for that provider; this relaxes only the issuer check;
• the provider publishes no usable signing key (jwks_uri) in its discovery document.

The full provider-side requirements are listed in the id_token requirements.

OpenID login fails with "SSO response validation failed"

The provider sent an iss parameter in the authorization response (RFC 9207) that does not match the issuer of the id_token — the server log shows a warning naming the RFC 9207 mix-up check. A correctly configured provider always satisfies this; if yours legitimately presents a different iss there (some multi-tenant setups), set DoNotValidateResponseIssuer for that provider — it relaxes only this check.

OpenID login fails with "does not advertise the required PKCE (S256) support"

The provider is marked Require PKCE (S256) (RequirePkce), but its discovery document does not list S256 under code_challenge_methods_supported — or the document could not be read at all. Enable PKCE with the S256 method at the identity provider, or clear the option to fall back to the default behavior (an [SSO Audit] warning is logged and the login proceeds). The support check is cached for about 15 minutes, so a provider-side change can take that long to be picked up.

SAML login is refused

Because SAML validation is fail-closed, a rejected login usually means one of:

• the response signature does not cover the consumed assertion, or is missing;
• the assertion is expired or not yet valid (check clock sync between your IdP and server);
• the assertion's AudienceRestriction does not match this service provider (set the expected audience, or opt out only if your provider cannot emit it);
• the same assertion was already used (replay);
• the browser-binding cookie is missing: a login started from Jellyfin must complete in the same browser, and the Secure cookie is only stored over HTTPS — on an HTTP-only deployment (no TLS at the browser edge) every SP-initiated login is refused. Serve SSO over HTTPS;
• the response's InResponseTo no longer matches an outstanding request: the login took longer than ~15 minutes, or the challenge and the callback landed on different instances behind a load balancer without sticky sessions (a lost correlation fails closed) — run a single instance or enable session affinity;
• ValidateInResponseTo is enabled and the login was started from the identity provider's dashboard (IdP-initiated) — that option refuses unsolicited responses by design; start the login from Jellyfin, or disable the option.

Check the server log for the specific [SSO entry.

"SSO login is not permitted for this account"

A first SSO login matched an existing, unlinked Jellyfin account with the same name. This is refused by default to prevent account takeover. If adopting that account is intended, enable AllowExistingAccountLink for the provider, or link it via /SSOViews/linking.

The plugin does not load

Make sure you copied the full publish output (all DLLs), not just SSO-Auth.dll. See Installation.

---

Still stuck? Open an issue with your Jellyfin version, plugin version, provider, and the relevant [SSO log lines (redact secrets).