How We Moved From Traditional Login to Awesome Login

Like many other SaaS platforms, Xeneta had its own proprietary login system, which was secure and powered by the excellent code written by our awesome developers.

However, more and more of our enterprise customers have been requesting single sign-on (SSO), and since we’ve been looking to implement additional multi-factor authentication options anyway, we decided that the time was right for an upgrade.

Now, we had two options to choose from — to design, build and maintain a new system ourselves, or to find a third-party solution. Naturally, we went with the latter, and what follows below is a brief story of the problems we faced along the way and how we managed to solve them.

What Is SSO

Put simply, SSO is when you log in to one platform and automatically log in to multiple other platforms or services without having to re-enter your login information.

A perfect example of this is Google’s services — when you sign in to Gmail, you can also access other Google apps like YouTube or Drive. Single sign-on is something we all use in our daily life without even thinking about it.

How SSO Works

To get a better idea of how SSO actually works, let’s take a look at the diagram below.

Flow with SSO

There’s a lot going on in that diagram, so let’s break it down into individual steps:

1. The user is browsing two websites (Step 1 and Step 8).
2. Both websites have their domain and a way to log in to it.
3. When the user tries to log in, both of them redirect the user to a third domain, a central Auth Server verifying the user’s identity (Step 2 and Step 11). Auth Server here is any identity provider like Azure AD or Google, where organizations securely store their users’ identities.
4. The user gets verified (Step 3 and Step 10).
5. Auth Server redirects the user to the respective website request along with the token containing basic details about the user in action.

Why SSO Is a Big Deal

Now that we know what SSO is and understand how it works, let’s ask an important question — why would anyone want to replace regular login with SSO?

To answer that question, let’s take a look at another example. Whenever you log in to a website using your Google credentials, you allow that website to only have some of your information to be able to sign in — there’s no need to create another login and password and store it on that website.

That’s the main advantage behind SSO and the main reason why so many companies are replacing the regular email and password login with it. Every enterprise has its identity provider, so it’s only natural for Xeneta customers to expect to be able to access our platform using their existing credentials as well.

Going Third Party

When evaluating if we should develop a custom system or go with an out-of-the-box solution, we concluded that moving forward with a third party would be a better choice since writing code from scratch would require too much effort and resources.

While looking for a system that fits our requirements, the team went through quite a few SSO solutions available on the market:

1. OneLogin
2. PingIdentity
3. Microsoft Azure
4. Auth0
5. Okta

Most of these platforms offer great functionality, but Auth0 was the one that matched our needs the best, so we decided to go with that. It not only offered us SSO but allowed us to basically replace our entire login system with a much more secure and easily customizable solution.

Can you trust your SSO provider?
Check that your provider of choice is fully compliant with the latest data protection standards like SOC2 and ISO27018.

From Plans to Reality

What if we told you that with a few clicks and a couple of redirects added to your code base, you could have a fully functional and secure login system?

This might sound like an exaggeration, but with top SSO providers, this is the reality — it took our team just a couple of months to fully master Auth0 and take advantage of its capabilities.

Auth0 provides a lot of customization options in the form of custom rules, actions, and hooks. With these options, we could change the flow to fit our specific needs and perform the required operations.

Rules, actions, and hooks are JavaScript code that you can use to customize the MFA flow, email verification, password expiration, etc.

Thought Process

Not everyone was fully on board with the idea of replacing our login system with an external tool at first. Naturally, there were quite a few questions, such as:

• “Why are we moving all of our login stuff to a third party?”
• “Isn’t our current login system secure enough?”
• Other similar (but equally valid) concerns

And to be fair, our old system was quite solid and secure, but doing authentication securely and correctly is no easy task. Not to mention the cost of maintaining it.

Since we were going to implement SSO via Auth0 either way, it made sense to us to take advantage of its authentication capabilities to improve our login experience as well. Combined with not having to worry about maintenance, security, and library updates, it was well worth the asking price.

Auth0 already supported most identity providers and SAML, so we didn’t expect any difficulties with implementing SSO.

SAML is a single point of entry that allows you to use any identity provider to set up SSO.

What We Got Out of the Box

SSO services typically offer an entire suite of features that handle everything related to login and authentication.

Here’s what we got with Auth0:

1. Multi-factor authentication. With just a click of a button, you can require all users to set up MFA. You can also customize it by adding your own rules.
2. Password security. Configurable security rules for password complexity, which we used to help our users choose more secure passwords.
3. Attack protection. Protection against brute force and bot attacks, password breaches, and more.
4. Branding. Branded design, with additional customization options via HTML and CSS — all within a convenient UI. We used this recently to promote our Xeneta Summit customer event directly on our login page.
5. Organizations. If you have enterprise customers with special login requirements, you can use the Organizations feature to set up custom authentication rules for each individual company.
6. User import. We didn’t need to worry about keeping user credentials locally and providing Auth0 with access to our DB.

These are the features we were primarily interested in, and once we understood all the rules, hooks, and actions, we could finally start doing some magic.

Start of the Journey

Since we already had a vast user database at Xeneta, we needed a solution where we could use our existing user table without having to run any migrations.

When we dug a bit deeper, we discovered that Auth0 could connect to our current DB and query directly from there.

Database engines supported by Auth0

So, we started with the infra changes. First, we created a read-only user for Auth0 with access only to selected tables. Next, we customized Auth0 to use our existing database to let the user log in and do all the necessary operations without making many changes.

Within a few months, we had a new login page that provided more secure access to our application and allowed our users to access it with their existing credentials.

Technical Challenges

It wouldn’t be a proper development journey without some challenges and roadblocks, and of course, we ran into our fair share of them while working on our cool new login experience.

Here are just a few examples:

How to release this big change safely?

It wouldn’t be very wise to release the new login page in its entirety to all customers right away without some proper testing first (in production, of course).

At Xeneta, we are already using a feature management solution to control our feature rollout. It allows us to release new features only to specific users or user groups, and that’s exactly what we did with Auth0.

At first, we released the new login to a couple of internal users, which helped us fix early bugs. The next step was releasing the new login to all of our employees, and as soon as we were sure that everything was going smoothly after a few weeks of internal testing, we replaced the old login page with the new solution for all of our customers.

After the full rollout, we closely monitored the authentication logs and support tickets, and once the majority of our users had successfully logged in with the new solution, we could finally breathe out.

What to expect from SSO?

Since this was our first experience implementing enterprise SSO, we didn’t know what to expect, so we started small.

We began by testing things out with our internal Azure AD — we failed a couple of times, but with the help of our fantastic colleagues and support from the provider, we made SSO work. To make sure that it was working well, we enabled it for a few internal users and started monitoring it.

Thanks to the feedback from our early adopters, we discovered that we had to find a workaround for our end-to-end test suite users — apparently, MFA doesn’t play very well with test automation.

How to migrate users with multi-factor authentication?

We already had MFA in our old login code, but unfortunately transferring or reusing it turned out to be practically impossible.

We really wanted to keep the new flow as similar to the old one as possible to minimize any user frustration, so we dug into the Auth0 docs and found out that there were rules that allowed us to customize the flow.

After some trial and error, we managed to develop a handful of custom rules that helped us recreate the flow that was close enough to what our customers were already familiar with.

Those of our users who had MFA enabled had to re-enable it once the new login was released, and thanks to an email with detailed instructions we had sent out to all customers well in advance, the whole thing went very smoothly.

Rules and Customization

Let’s say that after login you want to check the last time the user reset their password. If the date is more than 30 days ago — stop the user from logging in and show them an error asking them to update their password.

Here’s what the rule for this scenario would look like in Auth0:

The function name should be the same — that’s how Auth0 knows when to call this. It’s called after login and receives the authenticated user object as one of the parameters.

And just like that, with only 16 lines of code, we can change the flow the way we want.

Code Base Changes

With this integration now in place, we can safely remove a bunch of redundant logic from our code base and not worry about maintaining it.

All in all, we are looking at removing at least 3,000 lines of code that involved:

1. Login
2. Logout
3. Multi-factor authentication (MFA)
4. Password update
5. Email verification
6. Email update
7. Single sign-on (SSO)

Downsides of Third-Party SSO

Of course, no blog post would be complete without a list of downsides, so here are the ones that we discovered on our journey to implement a third-party SSO solution:

• Single point of failure. Moving the login functionality to a third-party system comes with a risk that — if the SSO service goes down, it could be a problem for us as well.
• Customization with rules. With a lot of different rules and directions that handle various scenarios, you have to always know which rules control which operation. Otherwise, the whole thing could turn into a bit of a mess.
• Limited customization. Since it’s a third-party tool, there are bound to be some things that you just can’t customize and have to settle for whatever the tool provides.

Xeneta is the leading ocean and air freight rate benchmarking and market analytics platform transforming the shipping and logistics industry. To learn more, visit www.xeneta.com.