Scenario
If one has to choose between Security Assertion Markup Language (SAML) and OpenID Connect (OIDC) for Single sign-on (SSO), it’s good to know the differences between each of them.
Recommendation
In most cases a customer or an application set the decision for a SSO standard. The following table will outline the benefits or tradeoffs. Please do not interpret this information to determine the “best” standard.
| SAML – Security Assertion Markup Language | OIDC – OpenID Connect | |
|---|---|---|
| Metadata URL | https://ucs-sso.domainname/simplesamlphp/saml2/idp/metadata.php |
https://ucs-sso.domain.name/.well-known/openid-configuration |
| underlying Protocol | XML | JSON |
| UCS interation | builtin by default | installed via the App Center |
| Allow user or group access to SSO | Adding a new external SAML service provider and assign them | Adding a new external OIDC service provider and assign predefined configuration openid-connect-provider
|
| Configure transmitted user attributes to SP | Yes | No, but requested attributes can be configured at the SP |
| SP initiated SSO | Yes | No |
| IdP initiated SSO | Yes | Yes |
| Example for preconfigured App Center Apps that work out of the box | NextCloud | None |
| Share certificates for loadbalancing in a multi server environment | builtin with stunnel | configure manually |
| Users can review requested attributes and deny access upon first login | No | Yes |
Further reading
Questions?
If you’re not sure whether the recommendations will fit into your scenario, please ask your Professional Services contact person, or create a new topic referencing this article.