Authentication frameworks have come a long way in the last decade. The old basic passwords have made way to new technologies due to today’s complex and dynamic cross-platform requirements. An ideal situation would involve a multi-method solution for your multi-tenant users. But how do you even get started? Let’s take a closer look at the lead authentication methodologies out there today and what’s best for you.
Before you even get started with picking the right authentication for SaaS applications, you should consider implementing Two-Factor Authentication (2FA), which has become a common requirement with the steep rise in cybercrime caused by accelerated digitalization across multiple sectors. This methodology involves the use of the One-time Password (OTP), which basically adds another layer of security.
If your application or website is handling sensitive information, Multi-factor Authentication (MFA) may be needed. This obviously is a less user-friendly option, unlike passwordless authentication for SaaS applications, another upcoming trend.
What is OAuth?
OAuth is essentially an authorization framework that was released as an open-standard all the way back in 2010, with companies like Google and Twitter adopting it almost instantly. It defines how various services can securely access (with authentication) data assets without sharing any credentials. This process is also commonly referred to as delegated authorization.
How Does OAuth Work?
First, a quick example. You can browse website www.demo.com and use your credentials from www.demo2.com to log into your account on the former, a classic OAuth use case. It’s important to understand that OAuth is all about authorization and it must not be confused with authentication, which is a different process altogether. Now that we have covered these clarifications, let’s get started.
Let’s return the aforementioned example and break down how OAuth powers the entire authorization process. Here is how it looks under the hood:
- www.demo.com connects to www.demo2.com upon the user’s request to log in and provides it with the user’s identity. OAuth is initiated
- www.demo2.com generates a one-time token and secret for the transaction
- The user’s client software delivers the token and secret to the authorization vendor. If not authenticated previously, a request is sent out to the client
- The user is granted a approved access token, used on www.demo.com
- www.demo.com sends the access token to www.demo2.com as proof of authentication. The user doesn’t need to do anything at this stage
- The transaction is complete. The user can use his www.demo.com account
The rapid adoption of this standard globally eventually led to the launch of OAuth 2.o (OAuth2) in 2012. We will be covering this extensively in our upcoming articles.
What is SAML?
Also known as Security Assertion Markup Language, SAML is an open framework that conveys authorization data from identity providers (Microsoft Active Directory, Microsoft Azure, etc.) to service providers (Salesforce, Box, etc.) in a secure way. This standard was created to simplify authentication and authorization processes for all involved parties in enterprises.
How does SAML work?
SAML is powered by Extensible Markup Language (XML), which enables the communication between the identity and the service provider. The communication is made in the form of XML documents, commonly referred to as SAML assertions. There are three types of SAML assertions that are always in play – authentication assertions, arribution assertions, and authorization assertions.
One SAML flow is initiated via the SAML-enabled service provider, where the user is redirected to the identity provider to handle the authentication process, following which access is granted or denied. The other flow is initiated by the identity provider where the user launches the service application after logging into the identity provider, following which automatic access is gained (assuming an account exists).
One of the biggest advantages of implementing SAML authentication and authorization is the ease-of-use. With users today depending on dozens of applications, SAML simplifies the log-in process and leads to fewer lost credentials since only one username and password combination is required. SAML also reduces the risk of identity theft with rampant techniques such as phishing.
OAuth vs SAML: The Comparison
While both standards serve their purpose and do a good job at what they are supposed to do, there are three main differences you should keep in mind.
1. Capabilities: SAML is More Comprehensive
Security Assertion Markup Language holds the advantage as it is capable of both authorization and authentication. On the other hand, OAuth needs to be implemented separately as it is solely an authorization protocol.
2. Different Formats
The OAuth protocol is based on the proven and tested JSON format. On the other hand. Extensible Markup Language (XML) is used in SAML transactions. This essentially lets identity and service providers standardize communications.
3. Use Cases: OAuth is Better for Mobile and Native Apps
While SAML can be the better option for enterprise applications or use cases, the tokens it implements are heavy. This can be a huge roadblock with mobile and native applications, where performance metrics are key to business continuity.
4. SAML Security is Tighter
While OAuth does have a provision for dynamic client registration, SAML is the better option as it allows tighter SSO/MFA implementation, while OAuth security lacks encryption, a key factor in today’s privacy laws (GDPR, CCPA, etc).
5. SAML is SSO-Friendly
Security Assertion Markup Language is more user-centric, while a single login can enable access to multiple applications, assuming they are supporting the protocol. On the other hand, OAuth is more application-centric, not a one-off solution.
Both standards are here to stay, as they all serve specific purposes and are suited to different use cases. More importantly, OAuth and SAML can be used together!
Quick(er) Implementation for Faster Results
Regardless of what standard you are opting for as a developer, you need fast results and smooth implementation to achieve your targets. Unfortunately, lack of manpower, time-to-market (TTM) factors, and budget constraints are leading to a wide variety of Identity and Access Management (IAM) issues today. That’s why you need to understand your use-cases correctly before picking one.
Frontegg takes it one step further. You can integrate Enterprise SSO with IdPs using protocols such as SAML, by integrating just 5 lines of code. Frontegg is multi-tenant by design, so on top of providing customers with full SSO integration, you also enable them to self-control every bit of configuration on their own tenant. This also allows you to focus on what matters most – your core technology.