By Zach DeMeyer Posted September 13, 2019
What’s the difference between SAML and OAuth? It’s a fairly common question for system administrators, security professionals, and application developers looking to improve their identity management posture and simplify the way users access resources with a common set of credentials. As organizations ponder the two concepts, it would be helpful to have a guide to differentiate between the two. Here is your guide for contrasting SAML vs. OAuth.
What is SAML?
The Security Assertion Markup Language (SAML) is a standard authentication (and occasionally authorization) protocol which is most often used by web application single sign-on (SSO) providers to relay credentials between an identity provider (IdP) which contains the credentials to verify a user and a service provider (SP) which is the resource that requires authentication. SAML uses extensible markup language (XML) metadata documents as its tokens for an assertion of a user’s identity. The process of SAML authentication and authorization (AuthN and AuthZ) is as follows.
Said another way, using SAML, developers can leverage SAML plugins to ensure their app or resource follows desireable single sign-on practices to simplify their user’s login experience and ensure security practices are laid in place to leverage a common identity strategy. That way, only an identity with the proper credentials/assertion can access an application. Additionally, SAML can be used to control what said identity can access in an application.
What is OAuth?
OAuth is more tailored towards access scoping than SAML. Access scoping is the practice of allowing only the bare minimum of access within the resource/app an identity requires once verified. For instance, OAuth is often used when a web app requests access to your system’s microphone and camera. This makes OAuth (specifically OAuth2) ideal for web/mobile apps, especially ones that can use Google, Facebook, or some other similar identity provider as a source of truth.
SAML vs OAuth
In general, SAML and OAuth are very similar; they both authenticate and authorize access regarding applications hosted in a web browser. When it comes to practice, though, they are obviously very different.
SAML is designed for situations like web app SSO solutions, where a central identity provider and an app are in communication and SAML facilitates the AuthN/AuthZ between them. OAuth is generally used by the applications themselves, using external IdPs to authenticate access and authorize permissions.
Another way to think about the difference is that SAML can generally be thought of as user centric versus OAuth tends to be more application centric. For example, a user will login to their single sign-on service and subsequently have access to their roster of SAML-based applications. With OAuth, a user will generally authenticate with each individual service and the application will have a one-to-one mapping with an IdP.
When it comes to an organization’s identity management, both protocols are useful, and, while not quite usable in concert, they can coexist peacefully. Because of that, however, it might be difficult to find an option for SAML and OAuth AuthN/AuthZ that isn’t a one-off point solution.
SAML + OAuth
There is an option available, a cloud directory service, that organizations can use to facilitate both SAML and OAuth usage for identity management. This solution is called JumpCloud® Directory-as-a-Service®, the first cloud directory service and identity provider.
JumpCloud natively uses the SAML protocol to directly communicate with hundreds of applications a la single sign-on. JumpCloud also directly integrates with Google and Office 365™ identities, meaning that it can control application access through OAuth as well, leveraging those sign-in mechanisms (e.g. “Sign in with Google”) using OAuth under the covers.
Beyond SAML and OAuth, JumpCloud also provides an additional array of standard authentication and authorization mechanisms such as LDAP and RADIUS to ensure users can leverage a single set of credentials across all of their resources ranging from web-apps to on prem resources like NAS appliances or legacy applications. The credentials also are leveraged for secure access to their macOS, Windows and Linux systems, ensuring the greatest totality of coverage a user’s identity can access securely. And, since it is a centralized identity provider with these capabilities, it offers admins the ability to provide their users with a single set of credentials to access all of these resources, all managed from a single cloud admin portal.