OIDC vs SAML: What’s the Difference?
OIDC vs. SAML: What’s the Difference?
Security Assertion Markup Language (SAML) vs. OpenID Connect (OIDC): It can be challenging to choose between the two and decide which is best for business.
Which is better: SAML or OIDC? Choosing between SAML or OIDC will depend on the use case. OIDC is better for more simple verification needs, whereas SAML is better for government or business uses because of the difference in security between the two protocols.
What Is an Authentication Protocol?
Security professionals discuss authentication broadly, addressing different approaches like biometrics and multi-factor authentication (MFA). However, some nitty-gritty technical details support authentication, including the protocols that support authentication.
With the growth of the world wide web and integrated applications, the necessity of strong authentication protocols has become even more evident. Rather than expecting users to remember dozens, even hundreds, of passwords or PINs, new advances in authentication have sought to centralize identity verification without reducing overall security.
To support such an endeavor, new approaches and technologies have emerged, including the following:
- Managed Identity Provider: Traditionally, identities are managed within the platform used–a Google ID for Google, Amazon for Amazon, etc. Security and UX specialists have quickly noticed that by leveraging more popular IDs, they can connect different platforms or applications under a single ID.
Thus, like many other services, the industry of Identity Management was born. Identity management providers (IdP) take over critical functions related to managing identities, including maintaining the uniqueness and security of a digital identity.
- Federated Identity: Federated identity uses the concept of an identity provider to expand authentication across multiple applications. By signing into one provider (serving as the IdP), you can gain access to another application. If you’ve ever logged into Google to access another application, you’re familiar with federated identity.
- Single Sign-On (SSO): SSO is a form of federated identity focused on a smaller context. While federated identity usually refers to authentication across multiple platforms or enterprises, SSO will apply to authentication within an enterprise (across all its internal applications and services).
How Does Federated Identity Work?
The user logs into the identity provider, who authenticates the user with whatever measures they employ (passwords, biometrics, MFA, etc.).
Once authenticated, the IdP securely sends authentication information. This might mean direct interaction with an SSO server for local SSO systems. For broader, federated public identity usually means passing information to the user’s browser that can be shared with a site or application.
The user’s browser passes the authentication material to the application, confirming that the user is authorized to access the system.
Tokens
Federated authentication doesn’t involve passing the actual credentials used to authenticate a user–this would provide too significant a security risk. Instead, these measures use “tokens,” or packets of data, that pass information between the authenticator (the IdP) and the application or platform.
Any discussion of SAML, OIDC, or other federated protocols, involves an understanding of the different forms of metadata that go into these tokens. “Metadata” is, as the name suggests, data about data. More precisely, metadata provides definitions and notations about a data object exchanged between different applications. The information can be parsed and transformed between apps, programming languages, or platforms.
Two languages discussed here include:
- Extensible Markup Language (XML): As a markup language, XML contains rules for encoding and decoding parts of data so that they can be rendered readable by humans and machines.
Like HTML, XML wraps information in “tags” that define what that information is so that other applications can parse it. XML is relatively simple to implement and serves numerous purposes in web applications representing data structures, but it requires a dedicated parser.
- JavaScript Object Notation (JSON): JSON, similar to XML, seeks to render data objects into a format that can translate across applications. However, JSON is more lightweight than XML and bases its structure and syntax on JavaScript rather than HTML. The purpose of JSON is to provide data interchange that is language-independent.
All things being equal between the two, JSON is the more robust and flexible way to represent complex data objects. At the same time, XML is the more secure and comprehensive way to represent complex data structures.
What Is Security Access Markup Language (SAML)?
SAML is one of the older forms of federated identity and authentication. Released in 2005, SAML uses XML to pass information from an IdP to an application via the user’s browser.
Taking the authentication flow from above, we can modify it to reflect a SAML workflow:
- A user attempts to access a webpage or app that requires authentication. Either the platform or the user decides to send a SAML request to an identity provider.
- The user enters their authentication credentials to the IdP. The IdP verifies their identity.
- Upon authentication, the IdP sends an encoded SAML assertion containing information about the user back to the app provider. This assertion is an XML document that will contain some basic parameters like the authentication issuer, the user ID, the time of authentication, and the provider.
- The user is allowed into the provider’s application.
SAML assertions can carry a variety of data types and are often used for authentication and resource authorization.
What Is OpenID Connect (OIDC)?
Open ID Connect provides the same workflow as SAML, with some minor changes. Published in 2014, OIDC is the third generation of the OpenID technology built on the OAuth protocol–a system primarily used for authorization but one that’s been expanded to include authentication services under OICOIDCD.
Some of the primary differences between SAML and OICD are the tokens. OIDC uses JSON tokens for assertions rather than XML. JSON tokens are smaller and easier to process while less feature-rich than their XML counterparts.
What Are the Differences Between SAML and OIDC?
These technologies are remarkably similar for the end user in that they accomplish the same task. And while there are differences between JSON and XML tokens, those differences are becoming less pronounced (leaning in favor of JSON due to its lightweight and interoperability).
Generally speaking, these two protocols will be leveraged in distinct use cases:
- SAML: SAML is typically used in cases where a user begins an authentication request (for example, when you select Google login to access another application).
Additionally, SAML is often used for authentication across different enterprise apps within an organization when a user logs into a central portal. Finally, as of this writing, more organizations in regulated industries will use SAML due to the security provided through XML.
- OIDC: Providing cross-authentication across mobile applications usually rely on the flexibility of OIDC and JSON. Furthermore, communications between programs through APIs (where object information may move through several different languages and frameworks) will often use OIDC.
Support SAML and OIDC with 1Kosmos BlockID
Federated identities and SSO are a new and sometimes critical part of modern authentication. These technologies help reduce attack surfaces and streamline the user experience to reduce threats related to poor cyber hygiene and phishing attacks.
Regardless, it is still crucial that the core identity management and authentication provider is secure and supportive of an enterprise’s users and infrastructure. 1Kosmos is such a provider, deploying identity and authentication tools to tackle the challenges of today and tomorrow. With passwordless authentication, decentralized identity management, and an intuitive user experience, 1Kosmos BlockID brings advanced security that integrates with SAML, OIDC, OAuth, and FIDO (among others).
With 1Kosmos, you can leverage the following features:
- SIM Binding: The BlockID application uses SMS verification, identity proofing, and SIM card authentication to create solid, robust, and secure device authentication from any employee’s phone.
- Identity-Based Authentication: We push biometrics and authentication into a new “who you are” paradigm. BlockID uses biometrics to identify individuals, not devices, through credential triangulation and identity verification.
- Cloud-Native Architecture: Flexible and scalable cloud architecture makes it simple to build applications using our standard API and SDK.
- Identity Proofing: BlockID verifies identity anywhere, anytime and on any device with over 99% accuracy.
- Privacy by Design: Embedding privacy into the design of our ecosystem is a core principle of 1Kosmos. We protect personally identifiable information in a distributed identity architecture and the encrypted data is only accessible by the user.
- Private and Permissioned Blockchain: 1Kosmos protects personally identifiable information in a private and permissioned blockchain, encrypts digital identities, and is only accessible by the user. The distributed properties ensure no databases to breach or honeypots for hackers to target.
- Interoperability: BlockID can readily integrate with existing infrastructure through its 50+ out-of-the-box integrations or via API/SDK.
To learn more about 1Kosmos Authenticators, read our datasheet here.
