With the introduction of the authentication standard SAML 2.0 coming soon to ZITADEL, you will be granted the possibility to choose between the two most trusted identity protocols: The previously implemented “OpenID Connect (OIDC)” and the new addition “Security Access Markup Language (SAML)”.
To help you determine which protocol is best suited for your use case, this article carefully explains the similarities and key differences between the two standards and what they each have to offer.
Both SAML and OIDC provide a means of authentication: They are responsible for securely transmitting user information between the system that is doing the authentication (the Identity Provider) and the service or application the user is attempting to access. Both standards offer centralized authentication, also called single sign-on (SSO), which allows the user to access multiple applications using a single login credential (username, password, token etc.). This process helps users to spare the time they would spend registering to multiple apps one-at-a-time, by maintaining a centralized database. A notable example of a SSO solution is Google: Using a single account, it is possible to access a wide variety of applications, such as Gmail, Youtube and Google Drive.
After having inspected what the two standards have in common, it is important to examine the characteristics that set them apart. While the key goal of SAML 2.0 and OIDC is identical, the approach used to authenticate users differs in method and technology.
Given the notable age difference between the protocols, the younger standard (OIDC) was developed with scalability and a simpler implementation in mind, to meet the expectations of today’s users, whereas SAML had more time to effectively establish a wider range of security features. To help us illustrate the main dissimilarities between the two standards more clearly, we have created the following table that provides an overview of these differences:
|Security||More trusted due to its exceptionally high security level, however even the basic security-features need to be implemented individually.||A newer protocol, which is actively being improved based on new threat vectors. Easier to adhere to 'best practice' code flows.|
|Implementation||Generally complex to implement and maintain; not recommended for mobile applications.||Very simple to implement and commonly used for mobile applications and single-page apps.|
|Message format||Sends heavy-weight XML messages for authentication via SOAP, a protocol layer on HTTP.||Passes light-weight JSON Web Tokens (JWT) or opaque tokens via RESTful API communication to exchange authentication information.|
|User consent||Consent flow requires hard-coding and is therefore not a built-in part of the protocol.||Offers a built-in layer of authorization (consent flow) that asks a user to consent to what the service provider might access.|
|Authentication process / Connectivity||To provide authentication, IdP and the relying party must be configured to know each other||IdP and the relying party don’t have to identify each other; faster and more resource-friendly|
|Biggest Strengths||Can offer the highest possible security, as there is a lot of customizable functionality, but only as long as the implementation covers certain security threads.||User-friendliness, interoperable with SPA and mobile applications, ongoing maintenance of the standard.|
|Biggest Weaknesses||Lengthy and complex implementation and maintenance of each feature one-by-one: higher risk of errors and malfunction.||Offers less features than SAML (f.e. dynamic specification of proxy IdPs is not fully supported).|
|Commonly used by:||Enterprise- and government-scale activities working with sensitive data.||Businesses highly prioritizing performance-friendliness and an additional implementation in mobile-applications.|
Which tool is best for you?
In conclusion, none of the two standards can be classified as the objectively better option: Ultimately, both will serve their main purpose of authentication in a safe and secure manner and are therefore equally well suited for traditional Web Applications. However, they do have their own respective advantages and disadvantages, which usually makes one of them the more practical choice depending on the specific usage context. To make a calculated choice on whether you should implement SAML or OIDC, it is essential to evaluate the core values, preferences, and the target audience of your organization. Accordingly, the final decision is only yours to make.
Given the previously mentioned differences between the standards, we can however give you some recommendations on the use cases for SAML and OIDC respectively:
- OIDC is probably the better choice if you do not want to invest in learning XML, or you need to work with Mobile- or SPA-type Applications or REST APIs. Also for green-field projects OIDC is typically the better pick between the two.
- If your application already has tools and libraries supporting SAML, then it is advised to continue with. SAML is also recommended if your business deals with sensitive data and requires the highest possible security.
- Should you be completely torn between the two standards, our general recommendation is to go with OIDC; due to its user-friendliness and easy implementation you will likely find it easier to pick up and maintain.
If you would like to enjoy the benefits of both standards to their fullest, you also have the possibility to adopt a hybrid usage: Since the two protocols serve the same purpose, but you’re not restricted to use the same protocol for all your applications, the best-used protocol can change for each of your organization’s applications.
In ZITADEL you can have both OIDC and SAML 2.0 applications within one project, sharing the same roles and user authentications. With token exchange between the two protocols, it will be possible to use both seamlessly for federated authentication across different client types.
How to proceed
Should you have questions regarding SAML and OIDC or any other related (or unrelated) topics, feel free to contact us anytime on our ZITADEL Discord Server. Alternatively, you can reach us on our Twitter, Linkedin or Github pages or on our Website.
Did you know that ZITADEL is OpenID Connect certified? Read more.
SAML 2.0 will be available on ZITADEL starting at the end of March 2022. Visit zitadel.com/roadmap for more information.