What is OIDC?
OpenID connect (OIDC) is an internet protocol that authenticates users trying to access online websites. It is built using the OAuth 2.0 framework, which allows identity providers (such as Google or FusinAuth) to verify a user’s identity by defining how an identity provider communicates with a service platform. In other words, OIDC works as a bouncer that grants access by asking authoritative figures (for example, Google or Facebook) if they know and recognize you. If everything checks out, OIDC lets you in, conveying information to the service about your identity and access rights in the process while keeping your password or other sensitive details private.
Like many other authentication protocols (Kerberos, LDAP, and OKI), OIDC supports a single sign-on (SSO) mechanism, allowing for a quick authentication process across several platforms. To put it simply, using protocols that support SSO lets you access multiple related but independent software systems with a single set of login credentials (for example, username and password) instead of requiring separate login methods for each different system.
Similarly to a password manager, SSO also reduces the need to remember passwords because it requires only one password to log in to the identity and access management (IAM) service. While fewer passwords also mean fewer brute-force attacks, it’s still important to be vigilant of potential cyber threats. The security of an SSO implementation heavily relies on the security of the single authentication point, meaning that if the identity provider is compromised, all linked services are at risk.
OIDC’s ability to securely authenticate users by extending OAuth 2.0 with an identity layer makes it one of the most popular authentication protocols between online service providers.
In addition, the OIDC protocol uses something called JSON web tokens (JWTs), which allow easier implementation and integration of authentication and authorization in modern web technologies. Along with this feature JSON token-based authentication uses specific web-generated tokens that the website generates upon your first login to the service. The token the website allocates to you includes your authentication credentials and is sent to your PC’s storage to use whenever you try to access the service. Instead of your username and password, the web service retrieves the token from your storage, identifies it, and allows you to access the service. That’s why you don’t need to always log in to some online websites you often use. The JWTs also have an expiration date. Therefore, sometimes, the website may ask you to log in using your username and password.
What is SAML?
Like OIDC, security assertion markup language (SAML) is an internet protocol for user authentication. It also supports SSO authentication. However, instead of JSON-based tokens, it uses Extensible markup language (XML) to share the authentication data. Drawing from the earlier bouncer comparison, compared to OIDC, SAML is more of a seasoned office security chief – a bit older and more complex but highly reliable and extensively proven in enterprise environments. To compete with OIDC’s simpler and more up-to-date features, SAML has introduced a new version of the protocol – SAML 2.0.
SAML vs. SAML 2.0
As expected, SAML 2.0 offers improvements and enhancements over its predecessor. Compared to SAML, SAML 2.0 includes additional features, such as attribute-based authorization and enhanced authentication options, making it better suited for modern web service architectures. The renewed SAML 2.0 protocol successfully builds upon the legacy of SAML with its improved functionality, security, and interoperability, making it one of the most popular authorization and authentication protocols online.
What is the difference between the SAML and OIDC protocols?
It is clear that SAML and OIDC are two of the best choices for online authentication protocols, particularly when integrated with OAuth 2.0 for authorization. But what are their main differences when compared side by side?
One of the most notable disparities between the two protocols is that OIDC is a much more modern option than SAML. While SAML is a safe, reliable, and widely adopted choice in enterprise settings, OIDC’s flexibility and easy implementation make it popular among modern web and mobile app developers. In addition, SAML uses XML digital signatures for message integrity and security, while OIDC offers a simpler and lighter approach, especially for developers familiar with JSON and RESTful application programming interfaces (APIs).
While both protocols are great tools for user identity management, they differ in their use cases. Due to its thorough security, SAML is much more popular in corporate environments and enterprises. OIDC, on the other hand, is much more attractive to consumer-facing app and social login scenario developers as it is well-suited for web-based SSO between different organizations. You can see how both protocols complete their user authentication and authorization processes below.
| Process | Step | SAML | Step | OpenID Connect |
|---|---|---|---|---|
| Authentication request | 1 | Access service provider (SP) resource sp.example.com | 1 | Access service provider (SP) resource sp.example.com |
| 2 | Create a SAML AuthnRequest and send a redirect to the browser | 2 | Create an OIDC authentication request with the desired parameters for the Authorization code flow | |
| 3 | Get a request to an Identity provider with SAML AuthnRequest | 3 | Get a request to the Identity provider/Authorization server with an OIDC request | |
| Authentication | 4 | Display the login page in a browser | 4 | Display the login page in a browser |
| 5 | User enters the credentials | 5 | User enters the credentials | |
| 6 | Validate the credentials and redirect the SP ACS URL with signed SAML Response in HTML form | 6 | Show the user consent page with all the attributes listed | |
| 7 | User accepts or rejects the consent | |||
| 8 | Redirect to SP redirect_url with the authorization code | |||
| Response validation | 7 | Post signed Response to SAML ACS URL | 9 | Get request to redirect_url with authorization code |
| 8 | Validate the signed Response, retrieve user attributes, and return the SP resource sp.example.com to the browser | 10 | Invoke Token endpoint with authorization code and get ID token, Access Token, and an optional Refresh Token | |
| 11 | Validate the ID token, retrieve user attributes, and return the SP resource sp.example.com to the browser |
