Most Common Challenges During Single Sign On Implementation

Why would companies need a centralized system for user identity and authorization management? A comprehensive answer to this question would require a thorough analysis of all the pros and cons of the solution. However, as this is not the subject of the article, I will focus exclusively on discussing the main benefits of implementing the Single Sign-On system.

 

First, we must realize that SSO can be applied to both — the company’s internal systems, giving employees more convenient access to corporate resources, and the customer-facing systems, that is, various applications, portals or websites that are provided to customers by the company and require registering and logging in.

I will attempt to discuss in detail all the main advantages and disadvantages of SSO for both of these applications in my next article. However, in this post, I would like to focus on the implementation of Single Sign-On in various types of systems dedicated for customers, both B2C and B2B.

 

Reasons why you may need SSO

Simplify customer journey

Without a doubt, Single Sign-On makes it easier for the user to access all the systems offered by the company, be it an online store, a blog, a product catalog, a loyalty program or a customer support portal. With this solution, the client can quickly and extremely conveniently switch between various company websites available to them.

After logging in to one application, the user can smoothly enter any other website without the need for re-authorization. Furthermore, they can seamlessly switch between all systems covered by SSO. The login screen is not displayed because the user has already been authorized automatically with SSO in each subsequent system. This obviously simplifies the customer journey, especially if the company operates, for example, several online stores under various brand names, offering different product ranges. In such cases, it’s quite usual that the customer can add products to a common shopping cart across all these e-commerce sites. SSO helps then to keep the client logged in all the time and enables them to move freely between relevant online stores and product detail pages.

One of the most well-known examples of SSO usage is a portfolio of Google’s web applications which includes Gmail, Google Maps, YouTube, Google Drive, Google Photos, and Google Calendar. All you need to do is sign in to one of the apps and from that moment you can freely switch between them to get access to the desired tool without any additional authorization.

 

Synchronise customer credentials between multiple systems

From the customer’s perspective, a great advantage of SSO is the ability to create and use only one set of authentication data which is valid for all the systems (websites) served by this solution. What’s very important, a new user has to create their credentials only once — when registering in a selected application where they are beginning their customer journey. Therefore, this is a completely different situation to the one in which the user creates identical logins and passwords for themselves separately on each page (what requires individual registration on each of the websites.)

Thanks to this solution, the customer no longer has to create and remember many different logins, user names, PINs and passwords. They can define one set of credentials for themselves and use it in each online application where SSO has been implemented. But that’s not all. With SSO, any single change of the authentication data made in one of the systems, e.g. when the user changed their password while being logged in to application A, also affects other customer-facing systems, i.e. applications B, C, D, etc. That way, the user doesn’t have to change the same information multiple times, separately in each company app they have been using.

This is possible since the client’s authorization process is managed by a central system which uses a common database where all credentials are stored.

 

Seamless customer experience

SSO allows companies to unify the authorization process across all customer-facing platforms. What does this mean? Once the solution is implemented, all systems it serves start using not only a common customer verification mechanism, but also the same login screen. Therefore, regardless of which website the user enters, when clicking the “Sign in” option or button, they will always be redirected to the same login page. In each case, they will see the same design, identical information, form fields and options, such as “Remember me” or “I forgot the password”.

The implementation of a common authorization process and a shared login page obviously reduces costs. There is no need to implement similar or even identical solutions several times within different applications. Moreover, this applies not only to the login process itself, but also to all related functionalities, including such features as changing a login and password or a password recovery option.

 

 

Centralized management of customers between e-commerce, CRM, ERP, etc.

Thanks to the SSO implementation, a company with multiple systems can store customer authentication data in a single, centralized database, regardless of whether the data is used by e-commerce, CRM, ERP or mobile applications. The data of all customers who are registered in these systems are stored in a central database.

Such solution may be useful in various processes related to customer service, e.g. during a conversation between a customer and a call center employee, when the latter must log in to the customer’s account to help them with a specific issue. In this case, the employee can find the customer in CRM, click the “Sign in” button, and then enter this customer’s account in an online store.

 

Security

Answering the question how the SSO implementation affects the level of security requires a deeper analysis, which I promise to provide in my next article on Single Sign-On. At this point, I will only point out that SSO may have a positive impact on security since with this solution the customer has to remember one password only, so they can make it more complicated and therefore much more secure. They can but they don’t have to…

On the other hand, there is the question of how different systems exchange login data or the information that a customer has already been logged in. It can be said that this slightly reduces the level of security, because in web applications, for example, it is handled with cookies. And we all know that cookies may be available to other users working on the same device, so theoretically someone could steal the specific cookie and use it on a different computer to log in automatically to another customer’s account.

 

Most common challenges during SSO implementation

Technical challenges with integration between systems

When a company decides to opt for Single Sign-On, the main technical challenges during implementation are related to the integration of various systems. This applies to both the architecture and security of these systems. Usually, companies operate an old-generation ERP system or an SAP-type system which — despite regular updates to newer versions — has the obsolete architecture. On the other hand, there are modern mobile applications and e-commerce sites built with much newer technologies.

In order to enable cooperation between these disparate technologies, some middleware is required, i.e. a solution that will sit between all these systems and provide them with the Single Sign-On functionality. There are many providers of this kind of services, i.e. the software that offers Single Sign-On features and can automatically authorize a user who logs in either to ERP, CRM, a website, or a mobile application.

What technical issue may occur here? Well, the system responsible for the Single Sign-On functionality — that is, the one that verifies the client’s login and password, and authorizes the customer in any other application — must somehow integrate with all the systems. In other words, it must inform the other apps that the customer has already logged in, order to find this user in the app database, and then set the person as authorized. Such integrations must be developed for each of the relevant applications, e.g. online store, website, blog, loyalty program, etc. The number of integration points is enormous and therefore it is a significant challenge to ensure that all these systems work together properly to provide the customer with seamless SSO experience.

In general, some of the out-of-the-box SSO systems can handle this type of integration, i.e. automatically communicate with SAP ERP or another popular ERP system. However, all websites are always custom solutions, regardless of whether they are based on SAP Commerce, Magento or any other engine. So when it comes to web applications, individual integrations must be dedicated for a specific solution, and — in fact — have to be written from scratch, separately for each web app. This, in turn, requires “agreeing” on the protocol, message format or how all errors are handled, e.g. what should happen if the customer entered an incorrect login or password, or they did it five times in a row.

All such cases must be handled in an appropriate way. Similarly, it must be planned in detail how the whole solution will behave in the event any of the systems involved is offline even for a few seconds, including the one responsible for SSO. How should this situation be managed? What will the customer see on the website? Handling all these exceptional situations brings considerable technical challenges.

 

 

Consistency in look & feel

Nowadays, most companies use (and offer to their customers) many different systems, including websites, mobile applications and ERP systems with obsolete graphical user interfaces (GUI) which often look as if they haven’t changed since the 1980s or 1990s. It is necessary to ensure that at least as far as authorization processes are concerned, all these systems have a similar appearance.

While a customer doesn’t have access to ERP or CRM — therefore it’s not so important to keep them visually consistent with other applications, all the customer-facing systems, like online shops, product catalogues, blogs or mobile apps, must present similar design and functionality.

Obviously, this can be achieved by unifying user interface architecture and design by consistently implementing the same policy and templates in all login screens in different applications. This can be achieved to some extent. But if these are separate (or even independent) projects with different teams, including their own dedicated product owners and front-end developers, it is very likely that despite using the same guidelines and standards, login pages will look a little different on other websites. This is due to the fact that each product owner has their own vision and will want to do it their own way.

The situation may be completely different if the company decides to opt for an SSO. From the moment the solution is implemented, different systems use only a common login page — a centrally hosted login screen, shared by all the applications. As a result, the login screen is identical in every customer-facing system, because, in fact, this is exactly the same page — a common step for all these systems.

 

Timelines coordination between all parties involved

A Single Sign-On project always involves multiple systems. Obviously, the task can be divided into several consecutive stages, that is, first we introduce SSO for only one selected system, e.g. online product catalog, then for another, e.g. e-commerce site, and so on — until the solution is fully operational in all customer-facing applications. However, this approach has significant drawbacks, since until SSO is implemented in at least 2 different systems, the user gets no benefits from it.

Furthermore, various systems may have different requirements for Single Sign-On. Suppose we have already two systems with SSO in place. When preparing a specification for the solution implementation in the third system, it may turn out that some of the requirements are completely contradictory to the previous ones. This means that we will have to rebuild the solution already implemented in the first two systems.

For this reason, it is recommended that SSO should be designed, developed and implemented simultaneously in all the relevant systems. If we do so, the benefits for both the company and the customer will be immediate — the user will be able to log in once and be authorized in any other website or app provided by the company.

This is a significant benefit for the customer, but a major challenge for the company, which has to face the coordination of the process of SSO implementation in multiple systems. Not every team has to start the implementation at the same time, but they all have to finish it simultaneously to enable the customer to immediately benefit from the solution.

As for ERP and CRM systems that are not available to the customer, they may be included in the solution later on. While company employees can wait for this convenience, customers annoyed by the multitude of login pages and credentials to keep in mind can easily leave for the competition that has already solved the problem.

 

 

Implementation challenges

In my analysis, I will focus solely on web solutions, such as online shops, product catalogues, loyalty programs, blogs or mobile applications. In this case, redirects are usually needed to handle Single Sign-On operations.

For example, let’s assume that a customer enters the loyalty program website and clicks the “Sign In” button. At the moment, the user is redirected to the centrally hosted common login page. Once logged in, they return to the website, or — what may happen if the customer (especially the B2B one) has multiple accounts within the system — a screen for selecting the desired account is displayed. The screen can be served either by the SSO system or by the specific system underneath — i.e. a loyalty program website, an online product catalogue or an e-commerce platform. My experience has taught me that the best solution is when the screen with a list of customer accounts is provided by Single Sign-On.

Another challenge is related to the large number of internet (www) domains being used. Let’s assume that the company has an online store, a separate loyalty program website, a blog with a login option (allowing logged users to publish their comments or download various assets), as well as a mobile application. On the other hand, there’s a unified and common login page — operated by the SSO system — and it is also available under its own domain that differs from the other websites. Now, we need, for example, to redirect the customer from the online store to the login page, and then — after successful logging in — send them back to the correct page, exactly the one the user is visiting right now. The difficulty is that the current page does not have to be the one on which the user started logging-in procedure since, in the meantime, they could go to another page (this case will be discussed further in the article.)

In addition, most websites offer the “Remember me” option on their login screens. When selected, it allows the SSO system to keep the user logged in for a specified period of time. Now, let’s assume that the customer has selected the option (checkbox) and logged in to one of the company’s websites (page A). After a few days, the same customer enters another website of the company (page B). When the portal is being loaded, a redirection to the SSO system is performed underneath (in a way that is invisible to the customer.) As a result, a cookie is detected in the browser which indicates that the user is logged in with the “Remember me” option selected. At this point, the SSO system returns to the page being viewed by the customer and passes by the information that they are already logged in. It’s worth pointing out that the entire login process is performed underneath through a series of redirects.

Various issues may occur while waiting for the authorization. The customer may, for example, go to another page within the portal before the login process is completed. In particular, this can happen when the user (still waiting for the authorization) unexpectedly became interested in a product, clicked it, and was transferred to the product detail page. At this point, all redirects must be restarted from the very beginning. This is a huge challenge since if the customer performs another click, once again it is necessary to stop the ongoing redirects, ignore the responses already received from the SSO system, and restart the whole process. Otherwise, the customer who is now viewing the product details will suddenly be taken back to the previous page as a result of the successful authorization.

The longer the redirects last, the more likely it is that the customer will start clicking within the website and go to another page. This complicates the authorization process enormously.

 

Performance impact

As mentioned above, the login process is mainly based on performing redirects between various systems and the SSO software. Whether the customer clicks the login button or the automatic login is performed as a result of selecting the “Remember me” option beforehand, all redirects must take a while. After all, this is a domain change, and a redirect to another website or system. Therefore, the customer has to wait a bit longer.

So if the SSO system slows down a little, all clients of every customer-facing system who try to log in or switch between websites are affected. Each user will have to spend a little more time logging in, whether in an online store or in a mobile application.

And what might be the reasons for the SSO system slowing down? Here is an example. Let’s assume that we have implemented the solution for two web applications. The SSO system had to support all logging requests coming from these two apps. Now, we added three new applications. That means three more groups of users have just started using the Single Sign-On solution. And it will slow down for sure, because more and more customers are starting to use the same SSO. Now it has to handle the traffic generated by five systems.

To summarize, the implementation of SSO undoubtedly has a negative impact on the performance of logging processes — I mean the time it takes to authorize and log in. In the case of SSO, the performance will always be worse than when the entire logging and authorization is done in each system separately. In order to reduce this problem, the SSO system should be provided with a suitable infrastructure so it could handle all requests faster.

Every middleware, i.e. an application that stands between other systems, usually has a negative impact on performance. Even if it is only a fraction of a second, it is always a delay that can be noticeable for the customer.

 

Potential problems analysis

When choosing SSO, the company must develop a strategy and procedures for solving problems reported by customers. Let’s assume that there are several customers who have trouble logging in to different systems. It is obvious that a customer always reports a problem on a website to which they cannot log in. Therefore, the user of the online shop will send their request to the customer service of the store, while a person using the loyalty program website will contact the relevant employees of the program.

All systems using the SSO solution — be it an online shop, a loyalty program or a mobile application — must have their support teams who will collect the customer’s request, analyze it and determine whether the problem originates in their own system, or in the Single Sign-On software, or maybe somewhere in between.

Ongoing analyses of issues reported by users can be very time consuming and complicated. Usually, the more systems are involved, the more complex the analysis of the problem is. Handling such user requests can be a huge challenge for the customer service teams. Finding in logs and interpreting information what could have gone wrong, what was the Single Sign-On response, whether the problem is on the application side, or maybe lies in the SSO software, etc. are not easy tasks. That’s why managing and analyzing the login issues reported by customers require the company’s employees to have more and more knowledge and skills.

In all systems accessible through web browsers, many issues related to Single Sign-On are dealt with by cookies, especially when it comes to the “Remember me” option. There may be situations where customer service staff have to instruct the user to delete cookies in their browser. Unfortunately, most customers have no idea how to do this and do not understand the instructions they receive. So this is certainly an additional complication.

 

*    *    *    *    *

 

In conclusion to this article, I would like to consider for a moment whether it is worthwhile to implement an SSO solution. You may be surprised, but there is no obvious answer to this question. Each company must decide for itself, taking into account the issues and challenges associated with this project, as well as the potential benefits it can bring. If you have a strong and experienced team that is able to handle the task, then SSO is certainly worth considering. Especially if you provide your customers with many different web applications, examples of which I have already listed in this article.

By the team I mean developers who can overcome all technological challenges, as well as user experience (UX) experts who will easily design a consistent and user-friendly interface. In addition, people who can manage the entire project and coordinate it over time, as well as professional customer support, which can be a single team that supports all systems, or multiple teams that work closely together.

As far as customer experience is concerned, the SSO system is only beneficial. The user logs in once and can switch seamlessly between different applications. In addition, when they log in with the “Remember me” option selected, they will not have to provide their credentials in any of the systems for a specified period of time.

Obviously, SSO also involves certain costs of implementation and purchasing or developing a system that supports the entire solution. Will the costs outweigh the benefits or will the benefits be greater for the organization? It’s up to the company to assess and decide for itself.

When assessing the relevance of SSO, you should also look at the customer profiles — whether it is beneficial for the company’s clients to have the ability to switch between different systems. Such an analysis may show that it’s of no importance for the majority of customers because the user groups of each application are mutually exclusive. One group of clients uses only system A, while the other logs in only to system B. In such a case, there is no point in implementing SSO.