SAML vs OAuth Introduction
Authentication is an important aspect of many systems, and sufficiently effective and secure authentication processes are vital for the operations of a huge number of companies and organisations. There are currently two main standards used for federated authentication—SAML and OAuth. The majority of systems will use one or the other of these two technologies.
Although SAML and OAuth are used for similar purposes, there are differences between the two that you may want to consider when choosing an authentication method for your organisation. In this guide, we will look at exactly how each of these technologies works and which may be the best for your needs.
What is Federated Authentication?
Authentication is the process of identifying a user’s credentials and that they are who they claim to be, rather than a user or program that may be attempting to fraudulently access a platform, application, or data. Authentication processes include the need for passwords or other forms of verification. Authentication can be as simple as requesting the user to provide the correct username and password, or more complex and secure, such as with Multi-Factor-Authentication (or MFA) systems.
Federated Authentication is when authentication grants a user access to multiple applications and/or platforms. A group of affiliated platforms/applications is known as a “federation”. Examples of federations include Microsoft’s Office applications (Word, Excel, PowerPoint,etc) and Google’s Workspace applications (Docs, Sheets, Drive, etc).
Both SAML and OAuth are used to carry out federated authentication.
OAuth was first launched in 2006 as a component of the OpenID implementation that is used by Twitter. In 2010, OAuth 1.0 was released, and OAuth 2.0 followed in 2012 and is the latest version at the time of writing. The terms “OAuth” and “OAuth 2.0” are often used interchangeably, such as in this article. OAuth uses HMAC-SHA—or Hash-based Message Authentication—signature strings.
OAuth works by defining four distinct roles; Resource Owner (a user who authorises a site or application to access their account), Client (the application itself that accesses the user’s account), Resource Server (the server that hosts the user’s resources), and Authorisation Server (the server that verifies the Resource Owner’s identity via their login credentials, and issues OAuth Bearer Tokens to the Client).
The OAuth workflow
The OAuth workflow is as follows:
- The client sends a request to the Resource Owner to access a resource held on the Resource Server.
- If the request is granted by the Resource Owner, an authorisation token known as an OAuth Bearer Token is granted to the Client.
- The Client uses this token to request an access token from the Authorisation Server’s API (Application Programming Interface).
- The Authorization Server verifies the identity of the Client.
- If this identity is valid, the Client receives an access token.
- The access token is used by the Client to request access to a resource held by the Resource Server.
- If the access token is valid, the Resource Server grants this access to the Client.
SAML stands for Security Assertion Markup Language. It is an open standard that is based on the XML text format, and it connects identity providers (or IdPs) with service providers (or SPs). SAML was launched in 2002, and approved by OASIS (the Organisation for the Advancement of Structured Information Standards) in 2003. In 2005, SAML 2.0 replaced the original version of the technology, and is still used today. When the term “SAML” is used nowadays, such as in this article, it generally refers to SAML 2.0!
The SAML system of authentication works by using XML-based security assertions—or “tokens”—that transfer identifying information about a user between an IdP and an SP. A well-known example of an IdP that uses SAML authentication is Microsoft Active Directory, which sends user data to any federated SP that the IdP interfaces with. SAML means that users only have to provide login credentials once in order to access a range of services. This is known as Single Sign-On, or SSO.
The SAML workflow
The SAML workflow is as follows:
- The user of (for example) a website clicks “Log In”. In this case, the website would be the SP and the user the “client”.
- The SP (website) creates an encrypted authentication request and sends it to the IdP.
- The SP (website) redirects the user’s browser to the IdP.
- The IdP carries out verification of the SAML authentication request.
- Once the authentication request has been verified as valid, the IdP provides a login screen for the user to enter their credentials (e.g. username and password).
- After the login has been carried out successfully, the IdP generates a SAML “token” representing the identity of the user.
- The IdP sends this token to the SP.
- The IdP redirects the user to the SP.
- The SP verifies the token and assigns the correct access permissions to the user.
- The user is logged into the service.
SAML vs OAuth: The difference between SAML 2.0 and OAuth 2.0
The main difference between SAML and OAuth is that SAML covers identity management, SSO, and federation, whereas OAuth deals specifically with authorisation and not authentication.
Authentication vs Authorisation
The terms “authorisation” and “authentication” are sometimes used interchangeably, however they are actually two different Identity and Access Management (IAM) processes.
Authentication is the process of a user’s identity being verified, whereas authorisation is the granting of specific access permissions to that user. Authentication includes techniques like SSO, MFA, and OTP (one-time passwords). Authorisation takes place after authentication.
Both processes play vital roles in an Identity and Access Management strategy. A simple way to remember which is which is to think of it this way; authentication is about the “Identity”, and authorisation is about the “Access”!
Is OAuth better than SAML?
The question of which standard is preferable is not a simple one. There is not a straightforward answer, as different organisations have different needs.
Both standards can be used as part of an SSO setup, but there are advantages of each. For example, SAML is generally considered to be more straightforward and secure, while OAuth is particularly suited towards mobile use.
The area in which OAuth provides the most benefits is in access scoping. If an organisation needs to configure a customised system of granting different users different levels of access to resources, some of which may only be temporary, OAuth is designed specifically for this through its use of API calls.
OAuth is also designed more for IoT (Internet of Things) devices such as mobile phones, tablets, and video games consoles than SAML is.
Can OAuth be combined with SAML?
So, can you use SAML and OAuth together? The simple answer is “yes”!
In order to do this, you can specify the SAML token to be recognised as an OAuth Bearer Token by OAuth’s Authorisation Server, which will grant the user access to resources. This means that you do not necessarily have to choose between either a SAML implementation or an OAuth one.