In short
For new integrations OIDC is usually the simpler choice: JSON instead of XML, a discovery URL and proper support for mobile and API clients. Pick SAML when the identity provider or the organisation requires it, for example ADFS setups or academic federations.
| Criterion | SAML | OIDC |
|---|---|---|
| Data format | XML assertions, signed (optionally encrypted) | JSON Web Tokens (JWT), signed |
| Transport | Browser redirect and HTTP POST to the SP | Redirects plus a back-channel call to the token endpoint |
| Configuration | Exchange metadata XML, upload certificates | Client ID, secret and discovery URL /.well-known/openid-configuration |
| Mobile and native apps | Awkward, in practice only via an embedded browser | Designed for it, with authorization code flow and PKCE |
| APIs and tokens | Not designed for it | Access tokens for APIs are part of the model (OAuth 2.0) |
| Logout | Single Logout is specified but often unreliable in practice | RP-initiated logout, also not always implemented consistently |
| Where you meet it | Enterprise, ADFS, academic and government federations | Modern IdPs, cloud services, Keycloak, Entra ID, Authentik |
| Troubleshooting | Base64-encoded XML in a POST, needs browser tools | Readable tokens, errors often right in the redirect URL |
| Nextcloud app | user_saml (SSO & SAML authentication) | user_oidc (OpenID Connect user backend) |
Pick SAML if …
- the IdP only offers SAML, such as an older ADFS or an academic federation.
- security explicitly requires signed and encrypted assertions.
- many applications are already connected via SAML and the team knows the flow.
- you only need browser logins and no token-based API access.
Pick OIDC if …
- you are building a new integration and the IdP supports both.
- mobile apps, desktop clients or APIs need to authenticate as well.
- you want to pass groups and attributes as claims without much mapping work.
- the team should be able to configure and debug it on its own.
Pitfalls from operations
- Expired SAML signing certificates: login breaks for everyone at once. Put expiry dates into monitoring.
- Clock skew between IdP and service: assertions and tokens are rejected as not yet or no longer valid. Check NTP everywhere.
- Wrong attribute as user ID: when email or name changes later, you get duplicate accounts. Use a stable, immutable ID.
- WebDAV, CalDAV and sync clients cannot do browser SSO. In Nextcloud plan for app passwords or the login flow.
FAQ
Can Nextcloud use SAML and OIDC at the same time?
Both apps can be installed, but in production you should settle on one login path per instance. Two parallel paths quickly lead to duplicate accounts and unclear ownership.
Is SAML less secure than OIDC?
Not inherently. Both are secure when configured correctly. Most problems come from misconfiguration, such as missing signature checks or overly long token lifetimes, not from the protocol itself.