What’s the Difference Between OAuth, OpenID Connect, and SAML?
There are as many ways to keep data safe as there are ways to attack it. From multi-factor authentication to single sign-on to on-premises firewalls, the options can be staggering. For developers and IT professionals, the choice of how to keep data and identities secure begins even sooner: choosing the standard that should be deployed to keep federated identity safe.
The decision isn’t always a straightforward one. Many struggle to distinguish between OAuth 2.0, OpenID Connect, and Security Assertion Markup Language (SAML), each of which brings structure to the federation process. This article brings clarity on what these standards mean, how they compare, and the purposes for which enterprises should use them.
We've also got a more focused comparison between SAML vs OAuth in another article if that's what you're looking for.
The Differences Between Standards
The main differentiator between these three players is that OAuth 2.0 is a framework that controls authorisation to a protected resource such as an application or a set of files, while OpenID Connect and SAML are both industry standards for federated authentication. That means that OAuth 2.0 is used in fundamentally different situations than the other two standards (examples of which can be seen below), and can be used simultaneously with either OpenID Connect or SAML.
Using either OpenID Connect or SAML independently, enterprises can achieve user authentication and deploy single sign-on. Though they both deal with logins, they have different strengths and weaknesses.
OpenID Connect is built on the OAuth 2.0 protocol and uses an additional JSON Web Token (JWT), called an ID token, to standardise areas that OAuth 2.0 leaves up to choice, such as scopes and endpoint discovery. It is specifically focused on user authentication and is widely used to enable user logins on consumer websites and mobile apps.
SAML is independent of OAuth, relying on an exchange of messages to authenticate in XML SAML format, as opposed to JWT. It is more commonly used to help enterprise users sign in to multiple applications using a single login.
OAuth 2.0 vs OpenID Connect vs SAML
Remember that it isn’t a question of which structure an organisation should use, but rather of when each one should be deployed. A strong identity solution will use these three structures to achieve different ends, depending on the kind of operations an enterprise needs to protect. Their use cases are as follows:
OAuth 2.0: If you’ve ever signed up to a new application and agreed to let it automatically source new contacts via Facebook or your phone contacts, then you’ve likely used OAuth 2.0. This standard provides secure delegated access. That means an application can take actions or access resources from a server on behalf of the user, without them having to share their credentials. It does this by allowing the identity provider (IdP) to issue tokens to third-party applications with the user’s approval.
OpenID Connect: If you’ve used your Google to sign in to applications like YouTube, or Facebook to log into an online shopping cart, then you’re familiar with this authentication option. OpenID Connect is an open standard that organisations use to authenticate users. IdPs use this so that users can sign in to the IdP, and then access other websites and apps without having to log in or share their sign-in information.
SAML: You’ve more likely experienced SAML authentication in action in the work environment. For example, it enables you to log into your corporate intranet or IdP and then access numerous additional services, such as Salesforce, Box, or Workday, without having to re-enter your credentials. SAML is an XML-based standard for exchanging authentication and authorisation data between IdPs and service providers to verify the user’s identity and permissions, then grant or deny their access to services.
Enterprises rely on web frameworks and protocols like OAuth 2.0, OpenID, and SAML to bring structure and security to federated identity. Knowing when to use each is a key step towards protecting your organisation’s data from the ground up.