Enhancing SaaS application security with SSO and MFA

In our previous posts we discussed in detail the generation of JWT tokens, how to secure them, and how to secure your users’ credentials and data on the databases.

That’s all great. But as the latest incidents — particularly Twitter’s Breach and Garmin’s ransomware — show, we need to question ourselves on how we should enhance the protection of our SaaS application users in order to eliminate the risk of sophisticated account takeovers and password breaches.

One of the most popular methods for enhancing SaaS application security is by applying SSO and MFA. But how do we implement them and what exactly does it mean for our users?

SSO-based authentication

When looking at enterprise grade applications, you can see that most of them allow signing in using Single Sign On. Enterprise ready applications will also support SAML as the SSO method.

The concept is clear. IT management wants to manage the employees’ identity in a central place. When a user leaves the organization his identity goes with him. IT cannot allow John.doe@acme.com to keep on using his acme.com identity after leaving the organization, right?

From the users’ perspective the motive is clear as well. Users sign up on multiple SaaS applications and websites and need to set their password on each of the applications and sites. In the best case scenario they will use a random password for each sign up. In the worst case and more common scenario they will use the same password for all SaaS applications. In case of a breach in one of them, the attacker will gain access to all of the other applications on which the user is registered. 

So IT wants control, and users want to avoid “password hell”. What’s the solution in this case? We need to use a Single Sign On (SSO) approach that will be controlled, monitored and provisioned by the IT administrator of the company which wants to use our SaaS service.

One of the most popular methods for enterprise SSO is the use of SAML

Security Assertion Markup Language (SAML) is an open standard that allows identity providers (IDP) to pass authorization credentials to service providers (SP). In other words, assuming you have a single identity at your identity provider, you should be able to login to all surrounding applications using that single identity.

The SAML flow has 2 main actors:

• The Identity Provider (IDP): The IDP is the single source of truth for the user’s identity. It is the only entity which holds data about users, their passwords and their entitlements.
• The Service Provider (SP): The SP is the 3rd party application consumed and used by the user.

Let’s see this flow in action.

For our example we’ll use a SaaS application called DemoSaaS. DemoSaaS is used by acme.com users. In our flow DemoSaaS is the SP and acme.com’s ActiveDirectory is the IDP.

• The user is prompted with a login form (usually input for email only). After inputing his email and pressing the “next” button, a call for validating if the user is registered for SSO is sent to the backend.
• In case the user’s domain is registered for SSO using SAML, the user is redirected to his company’s IDP for login. The redirect uses the browser by sending a SAML request.
• The IDP performs the authentication check and the entitlement check (that this user can actually access the Service Provider’s application) And redirects back to the ACS (Assertion Consumer Service) which is in this case the DemoSaaS.
• The Service Provider validates the assertion response and the signature (validating that the originator is actually the claimed IDP) and lets the user in by providing a JWT token.

So we discussed the SAML requests and SAML responses. But what exactly is SAML?

SAML is basically XML with assertion units. The spec and protocol for SAML2 was written and maintained by OASIS where the full specifications of the protocol can be found.

An example of SAML authentication request will look like this for DemoSaaS (Our service provider):

Upon successful login, the IDP will return the following Authentication Response:

ℹ️ There are a few items to pay attention to in the flow above:

• The SP request contains sequence ID which is returned by the IDP in the “InReponseTo” attribute. This is done in order to eliminate a mixup of requests and responses.
• The IDP issues the email of the logged in user by using the “nameId” attribute. Usually, on each IDP there are multiple configurations which allow to set the nameId attribute to other identifiers of the user rather than his email address.
• The IDP issues a “NotBefore” and “NotOnOrAfter” attributes on the response. This is done in order to eliminate MIM attacks and replay attacks in case the connection is intercepted.
• The response is signed on using the IDP’s private key. The verification of the response is done by using the IDP public key and is the responsibility of the Service Provider.

Multi-factor authentication

Multi-factor authentication (MFA) refers to an authentication method where the user is required to present at least 2 valid “evidences” that he is actually the user he claims to be.

Before he does that? He cannot login…

One of the common types of MFA is Two-factor authentication (also known as 2FA). 2FA verifies that in addition to “something you know” (for example username and password) you can verify your identity via “something you have” (for example phone for SMS / Authenticator app).

The common factors you can find out there, sorted by security level, are:

• Authenticator app: Using TOTP protocol and using one of the authenticator applications (such as Google Authenticator, Duo, Microsoft Authenticator etc.), the user is pushed with a verification code (that is usually refreshed every 30 seconds), inputs the code, then the backend verifies the validity of the code.
• SMS: User is sent a code (that expires after X minutes) to his phone via SMS and needs to input it on a dedicated screen.
• Email: User is sent a code (that expires after X minutes) to his email box and needs to input it on a dedicated screen.

The second factor of authentication here proves that the user which is trying to perform the action in the system is actually the one that he claims to be.

The common flows on which we find requirements for 2FA validation:

• Login — The user inputs his email and password. If they are correct, for the next step he will need to input his one time token for second level validation.
• Change password — In case a user tries to change her password, we will send the user an email with OTP in order to validate that the account is not compromised before actually changing the password.
• Delete account — Same as for password change. In case the user tries to delete the account, we would want to validate by sending the user an additional OTP over to his Email / SMS in order for him to validate his identity before actually deleting the account.

OK. So we have the flows. But what actually happens behind the scenes?

Let’s take the login challenge for example (the components were simplified for the visibility of the flow):

• The user inputs an email and password.
• The application verifies the correctness of the credentials (which are saved securely on the DB LINK).
• The application generates the MFA challenge (in case of SMS / Email sends the relevant code) and saves the code on cache (preferably a distributed one like REDIS) with a new uuid as the MFA token with expiration. The MFA token is returned to the user.
• The user performs the challenge (SMS/Email/TOTP) and sends the result using the MFA token. Backend validates the challenge with the token and invalidates the cache.
• A JWT is generated and the user is now authenticated.

Cool! We now have a validated user through two different factors of authentication! The login process is secured!

As per the usual, there are a few considerations for choosing the right 2FA method:

• SMS —SMS is great for easy and quick onboarding. You don’t need the user to install an additional application. We all have phones and it seems like the easy way, right? But — just try to google the term “sms hijack”…

• Email — Just like SMS, emails are great for easy and quick onboarding. We don’t ask our users to install any additional application. The problem with email as a 2FA delivery channel is that the most common first factor, a password, can usually be reset via an email. That means that an attacker only has to compromise one factor, your email inbox, to take over your account.
• Authenticator applications — Authenticator applications use secure TOTP protocols, but security comes with a usability price tag. it requires the user to install a dedicated application on the user’s phone and issues headaches (using recovery codes or support tickets).

So the key here is to balance between your security requirements and user experience goals.

Summary

The essentials of security on every SaaS application require us to protect the users of our SaaS application.

This is basically a non-negotiable requirement, both from a compliance point of view and especially in the face of the growing scope and sophistication of breaches.

As SaaS owners we need to enable an SAML IDP sign on and enhance account security by providing an additional factor for our users’ authentication method.

Start For Free