SAML vs. OAuth vs. OIDC
How To Choose an SSO Protocol
When devising a plan to keep data and identities secure, IT administrators and security analysts must first select the protocol or framework to deploy to keep federated identity, or the means of connecting a person's electronic identity and attributes, safe.
The benefit of single sign-on (SSO) is that employees can log in once to an application or network and not need to keep logging in to different applications or networks throughout the duration of the workday.
While this is certainly convenient for employees—making them more productive because they do not have to remember multiple passwords—it is also convenient for IT. With fewer passwords registered in the system, the identity and access management (IAM) platform responsible for managing employees' credentials is more manageable.
However, it is no easy decision. The two main contenders in the federation process are Security Assertion Markup Language (SAML) and open authorization (OAuth). Let us take a look at these technologies more closely.
SAML is a protocol that lets an identity provider (IdP) transmit a user's credentials to a service provider (SP) to both authenticate and authorize that user to access a service. SAML simplifies password management and enables SSO. It is helpful for enterprises because employees access more and more applications to carry out their jobs. In fact, according to a study by Okta, large companies use an average of 129 software applications and nearly 10% of businesses deploy more than 200 applications in their enterprise IT systems.
Managing passwords for hundreds of applications used by hundreds or even thousands of employees can be extremely challenging. SAML comes to the rescue by offering enterprise SSO.
OAuth 2.0 is a standard for secure authorization. It provides secure delegated access and does this by giving access tokens to third-party services without exposing user credentials. However, it only authorizes—it does not authenticate. For authentication, the OpenID Connect (OIDC) standard is used. Identity providers, or those that create and manage identities, use OIDC so users can first sign in with their IdP and then access applications without having to log in and share credentials.
Although open authorization performs better on mobile devices, largely because it is built on the more lightweight JSON open standard file format for encoding data, it is not robust enough for enterprise use, especially since it only authorizes users and does not authenticate them.
What Are the Differences Between SAML and OAuth?
SAML is designed for authentication and authorization while OAuth was built solely for authorization. Understanding the different purposes of each key to understanding how an access management system works.
The envelope of credentials for each user is stored in a token. The SAML token is known as a SAML assertion. In OAuth, it is known as an access token.
When a user logs in to a service, such as a document-sharing service or customer relationship management (CRM) database, the following flows occur:
- For SAML: The first step is user authentication. The SP makes a SAML authentication request to the IdP, redirecting the user's browser to the IdP for authentication. The user then enters their credentials (username and password) into the form. Once logged in, the IdP generates the SAML assertion (token) and sends it to the SP. The SP verifies the SAML assertion, takes the user identity along with the proper permissions (authorization for certain features or data access), and logs the user in to the service.
- For OAuth: The process is similar except there is no encryption of the access tokens and only authorization is granted, not authentication of identity.
SAML is designed to focus on enterprise security, while OAuth, because it lacks encryption and relies on secure sockets layer/transport layer security (SSL/TLS) protocols for security, is generally not a good choice for securing an enterprise of hundreds or thousands of employees.
When To Use SAML and When To Use OAuth
Although SAML may seem superior in enterprise settings, there are some scenarios where OAuth makes sense.
- Identity management for a government application: Use SAML. The confidential, sensitive nature of government data needs the strongest security possible.
- User experience is a priority: Use OAuth. It performs better on mobile.
- Mobile and consumer applications: Use OAuth. It performs better on mobile, and consumer login sessions tend to be shorter.
- Virtual desktop infrastructure (VDI) implementation: Use SAML. The VDI will be used by a number of employees within the enterprise.
- Temporary access is needed for resources: Use OAuth. It is more lightweight.
How SAML and OAuth Can Work Together
SAML and OAuth can be used together. A SAML assertion and an OAuth token can both be used to access a protected resource.
SAML vs. OAuth vs. OIDC
OAuth controls authorization to a protected resource, such as a set of files. It does not authenticate the user and does not authorize the user to access all parts of an application—only certain ones. SAML and OIDC are protocols for federated authentication or the verification of the link between an identity and its attributes. OAuth can be used simultaneously with either authentication standard.
SAML and OAuth Support Federated Identity Solutions
The Fortinet IAM solution allows IT administrators to securely confirm the identities of users and devices as they enter the corporate network and interact with devices and applications. IAM is critical for organizations that have adopted the zero-trust networking philosophy, which states that no one should be trusted unless their identity has been verified.
The Fortinet IAM, which includes FortiAuthenticator and FortiToken, allows organizations to control and manage identity at all times. This ensures that authenticated users are authorized to access the right devices, applications, and systems at the right time, while protecting against unauthorized access. SAML, OAuth, and OIDC are standards used in Fortinet SSO and Fortinet IAM.