Single Sign-On and Passwordless Authentication are crucial technologies for protecting against cyber attacks, especially in cloud systems. Most solutions are facilitated by one of two security standards: Security Assertion Markup Language (SAML) or OpenID Connect (OIDC). While the two protocols are both designed to achieve the same thing – secure transmission of authentication data – they also have significant differences in technology and use cases.
Terminology
The terminology used by both protocols differs slightly. The data sent via the protocol is known as ‘claims’ in OIDC, and a ‘SAML assertion’ in SAML. In addition, the application that redirects the user to the Identity Provider is known as the ‘Relying Party’ in OIDC, and the ‘Service Provider’ in SAML.
What SAML and OIDC are used for
While SAML and OIDC have many differences, there is also commonality between the two protocols. Both protocols perform the same function and exist in the same space – to communicate data securely between two parties, usually an Identity Provider (IdP) and a Service Provider (SP) or Relying Party (RP). This is done in the form of a claim or SAML assertion, which contains all of the security information necessary to verify the user.
The basic process of operation is the same for both – the user can initiate the process either by accessing the IdP or SP first. In the case of the latter, the SP then sends an authentication request to the IdP, which performs the task of verifying the user. This confirmation is then sent in a secure token back to the SP, which authorises the user access to the service.
The user experience is fundamentally the same, a smooth and secure passwordless Single Sign-On solution. There are, though, significant differences at play which developers and IT professionals should consider.
Server to sever vs server to client
When authentication data is sent via a SAML assertion, it is always facilitated via server to client. This means that the assertion is sent from the IdP or SP (the server) to the user (the client) first, usually directly to their web browser, before being passed on to the other server.
Conversely, OIDC facilitates sending authentication data (the ‘claims’) from server to server, allowing the IdP and SP to communicate with one another directly. Since a combination of both methods is usually used, this adds a slight extra layer of security by splitting up the claims into two parts, requiring both to be compromised for the data to be usable by a hacker.
JSON vs XML
One of the key technical differences is the method by which the data is transmitted between the three parties involved in a typical authentication process. SAML assertions are formatted in XML, whereas OIDC claims are formatted as JSON Web Tokens (JWTs). Since JWTs are much smaller than SAML assertions, they can be easily sent between the three parties, such as through a URL or HTTP header, making them quicker to transmit and easier to scale.
SAML and OIDC use cases
Typically, applications will only support one of the two protocols, meaning developers will need to decide which one best suits their needs. While the process flow may be similar for both, one is likely to be the better choice depending on the environment.
The crucial difference is that of scale – OIDC is designed to be more lightweight, faster, and therefore suitable to internet-scale systems, able to process large numbers of claims in large networks very quickly. This makes it ideal for mobile apps, landing pages, web apps, and most consumer-facing environments. Almost all social media websites, for example, use OIDC to provide Federated Access.
SAML, by contrast, is more frequently used in enterprise environments, with Single Sign-On being by far the most common use. While SAML is an older standard, its maturity and reliability makes it attractive in enterprise environments, where it is widely recognised and compatible with both modern and legacy applications alike.
Ultimately, the use case is best determined by the factors of scale, environment, and native support. While OIDC is far more commonly used by consumers, SAML still remains the most utilised solution for enterprise Single Sign-On and passwordless authentication. While there is speculation that eventually it will be completely replaced by OIDC, its reliability and compatibility mean that it’s not going anywhere for now.
Find out more: Delve deeper into SAML and how it works.
