one-login

One Login to Rule Them All: Understanding and Integrating With Single Sign On


Who’s reading?

Through this blog, we aim to provide valuable insights and guidance for product managers and novice developers on the topic of Single Sign-On (SSO). Here, you will learn about the importance of SSO and how to navigate the process of choosing a provider and integrating it into your system. Additionally, for those more experienced in the field, this blog will offer a glimpse into the decision-making process at PayGlocal when it comes to selecting technical partners. Whether you're new to SSO or a seasoned pro, there's something for everyone to gain from reading this blog.

The Login Dilemma: Security vs Simplicity

In 2013, a well-respected organisation reported that all 3 billion of the company's accounts were compromised in a data breach. The hackers were able to steal personal information, including names, email addresses, phone numbers, dates of birth, and security questions and answers. This resulted in a huge loss of trust among users and significant financial losses for the company. This incident shows how important it is to have robust security measures in place to protect against hacking attempts and data breaches. Hence,authentication and authorization security systems are essential for protecting sensitive user information.

However, when security systems on applications become too complicated for users, it can lead to a number of negative consequences, like:

  1. High Dropout Rate: It can result in a high dropout rate, as users may become frustrated with the process and choose to abandon the application altogether.
  2. User Mistakes: If users are unable to understand or navigate the security system, they may inadvertently make mistakes that could compromise their own security, such as using weak passwords or sharing sensitive information with the wrong parties.
  3. Security Workarounds: It can lead to users resorting to workarounds that compromise the security of the application, such as writing down passwords, sharing them with others, or even disabling the security features altogether.

This can create a false sense of security and open up vulnerabilities in the system that could be exploited by hackers or cybercriminals. In short, a security system that is too complicated for users will fail to protect sensitive user information, the very thing it was created to do.

Now comes the million dollar question: Security vs Simplicity, how do you strike the right balance? And the million-dollar answer, Single Sign-On Solutions!

Single Sign-On: Striking the Right Balance

Single Sign-On (SSO) solutions provide security without compromising the usability of your application by:

  1. Providing Security: Providing a secure protocol for logging-in that is backed by tech giants like Google, Apple, Facebook, etc. This ensures the highest standards of security is used during the login process.
  2. Instilling Confidence: Enabling ease of user login to different platforms using credentials from the above-mentioned platforms. This instills confidence and simplifies the process, all while maintaining security.
  3. Providing Simplicity: Enabling users to securely log into multiple platforms using a single set of credentials. This removes the need to shuffle through multiple credentials as users interact with a countless number of applications each day.

SSO solutions provide organisations the right balance between security and simplicity! But is it worth the integration effort? Let’s find out.

To Integrate or Not to Integrate?

Single Sign-On (SSO) can simplify the login process for users and increase security for organisations, however, it's not always the best solution for all use cases. In this section, we will take a closer look at the pros and cons of SSO integration and help you decide whether it's worth it for your organisation.

Click Here

Despite the few cons, SSO is a great enhancement for any application. It strengthens the user experience through a more refined consumer login experience.

By now, you should be convinced of how a SSO integration would be good for your organisation and you would want to dive right into its integration. But before that, let’s get an understanding of the basics of SSO security and how exactly SSO works.

SSO Security: Authentication and Authorization

Authentication is the process of verifying a user's identity, while authorization establishes a user's access to specific resources. Think of it like using your ID card at your college. The ID card tells the security guard at the campus that you are a student or teacher at your college, but it also allows you access to only a particular set of amenities and resources at your college based on whether you are a teacher or a student.

When deciding on an SSO integration, it's important to take into account the company's overall security posture and understand whether to use both authentication and authorization or either one. Now let us understand how SSO works and provides these services to users.

Decoding SSO: How Does it Work

developer

Single Sign-On (SSO) is a method of authenticating a user to multiple systems and applications with a single set of credentials. This process is depicted in the above diagram, and involves three main components: an Identity Provider (IDP), a Service Provider (SP), and the user. To facilitate the connection between the IDP and the Service Provider, SaaS-based SSO solutions are used. These solutions act as a middleman between the two, allowing for a smooth and seamless login process.

Now, are we good to get started with the integration? Well, not really. Navigating through the sheer number of integration types for SSO-based integrations is pretty tricky. SSO solutions provide a wide variety of features and authentication flows leading into multiple decision points. Thus, having a soundtechnical decision-making skill is essential during this process, which we shall discuss in the next section.

The Art of Technical Decision Making

Before anything else, preparation is the key to success.” - Alexander Graham Bell

While developing products and features for an organisation, developers always stumble upon a range of decision points. Hence, it is key to ensure that decisions are made in a systematic and swift manner to avoid diving into analysis paralysis. There are some key points to keep in mind while making a technical decision:

  1. Always have the problem statement in mind: Deviations from the problem statement can arise during research. An open mind finds opportunities, while a focused open mind takes action on those opportunities.
  2. Do Proof of Concepts (POC) wherever required: When checking out vendors or flows, performing POCs brings more clarity than hours spent reading.
  3. Price evaluation: The pricing of solutions is critical to making the right decision. A free, open-source solution with fewer features is better than a priced, feature-rich solution, as long as it solves the problem.
  4. Document: Always document the pros and cons, POC results, and other relevant information about all the choices present. This is good practice if someone wants to revisit the solution and understand how certain decisions were made or even make enhancements in the future.

Performing systematic research to come up with a viable and secure SSO integration is essential, and the next section shows the reader one of the many ways to solve a SSO integration maze.

The SSO Integration Maze

Navigating the SSO integration space can be a challenging task due to the wide range of options available. With so many vendors and integration types to choose from, it can be difficult to know where to start. A simple google search for "SSO integrations" may only provide a small glimpse of the vast options that exist, making it hard to identify the right solution for a particular application. It is important to navigate through this maze correctly, as the wrong integration choice can have negative consequences:

  • Unusable Platform: It can result in poor user adoption, low security, or even data breaches, and can have a negative impact on the overall success of the product. For example, if you only support Apple as a sign-on provider, non-Apple users will not be able to use your application.
  • Incorrect Integration: It can make your integration difficult, non-seamless, and not align with the company's security policies, compliance requirements, and regulations. SSO integrations use different technologies and provide different features for authentication and authorization, and utilising the correct one will save the organisation money and developer bandwidth.

Solving the SSO Integration Maze

Let us assume there exists an organisation that is developing a product for the B2C segment for accepting international payments from consumers across the globe. The organisation had already developed their own authentication and authorization flows for their APIs, as they value security and it is a core principle of the organisation. From a tech stack perspective, the organisation uses a regular web application executing on a server that communicates with a separate backend server. This organisation wants to integrate with a SSO provider. Let’s check out their journey in solving the integration maze.

Decision Point 1: SSO Features

To connect to consumers around the globe, the organisation requires a login solution that:

  1. Would securely authenticate users.
  2. Was familiar to users as we needed a good acceptance rate for our platform.
  3. Was simple to use by the consumers, as we wanted fewer abandonments.

As the organisation had already developed their own authentication and authorization flows for their APIs, theclear requirement for the integration was the authentication of the users. Other features would not be required for this product, such as authorization, user risk control, etc., which are provided by the SSO partners.

Decision Point 2: SSO Protocol

Different protocols are used for SSO flows, two of them being Open ID Connect (OIDC) and Security Assertion Markup Language (SAML). Apart from the low-level flow of authentication being different, the tokens given out after authentication are different too. In the OIDC protocol, after a user is authenticated by the IDP, a JWT token is returned, while in SAML, an XML document called a SAML assertion is returned.

Even though SAML is more mature and has more features, for a simple identity-based authentication solution, OIDC is becoming more popular in the space due to the ease of handling JWT tokens when compared to XML documents.

These tokens contain the identity information of the user, and handling them in a secure manner is therefore critical. Since the organisation emphasizes simplicity, security, and functionality for any feature that is developed, adopting the OIDC protocol for their SSO integration would be an obvious choice as it helps setup a simple authentication system using a quick integration.

Decision Point 3: SSO Flow

When using the OIDC protocol, which is an extension of the OAuth protocol, there are several flows that can be utilised for SSO integration. Choosing the right one is necessary for a secure and smooth SSO experience, and the choice is influenced by the technical architecture of the organisation. Auth0 has put out a brilliant article stating how this flow can be decided for a particular platform.

Since the organisation uses a regular web application executing on a server that communicates with a separate backend server, the recommended flow type is the authorization code flow, which is the most common and safest flow available. After the flow is executed, the web application will receive an JWT access token, which contains the user’s identity information that can be utilised by the platform. The access token will be sent to the backend server, which will verify the token using the public certificate provided by the SSO vendor. When verified, the user is authenticated to access the resources on the service provider’s platform.

Decision Point 2: SSO Protocol

Different protocols are used for SSO flows, two of them being Open ID Connect (OIDC) and Security Assertion Markup Language (SAML). Apart from the low-level flow of authentication being different, the tokens given out after authentication are different too. In the OIDC protocol, after a user is authenticated by the IDP, a JWT token is returned, while in SAML, an XML document called a SAML assertion is returned.

Even though SAML is more mature and has more features, for a simple identity-based authentication solution, OIDC is becoming more popular in the space due to the ease of handling JWT tokens when compared to XML documents.

These tokens contain the identity information of the user, and handling them in a secure manner is therefore critical. Since the organisation emphasizes simplicity, security, and functionality for any feature that is developed, adopting the OIDC protocol for their SSO integration would be an obvious choice as it helps setup a simple authentication system using a quick integration.

Decision Point 4: SSO Vendor

There are numerous SSO vendors in the market that provide SSO as a SaaS solution. The choice of the vendor depends on the feature set, protocol, and flow required for an organisation’s SSO solution. For the purpose of this article, a comparative study was conducted between auth0 and firebase, and the observations were as follows:

  1. Auth0 is easier to integrate, feature-rich, and more secure, but has features that might not be utilised on our platform.
  2. OAuth 2.0 from Firebase is comparatively more involved to implement because of the generic SDK, but it provides much finer control over the authentication process, and the costs are comparatively lower.
  3. The data in the access token and the verification of the access token are the same across both platforms.

Thus, while Auth0 provides better functionalities, is lighter, and is very focused on authentication, Firebase solves the problem at a much lower cost. Hence, choosing Firebase as the SSO solution provider for the organisation would be a great choice. With this said, let’s move on to our step-by-step guide on how to integrate with Firebase!

Decision Point 2: SSO Protocol

Different protocols are used for SSO flows, two of them being Open ID Connect (OIDC) and Security Assertion Markup Language (SAML). Apart from the low-level flow of authentication being different, the tokens given out after authentication are different too. In the OIDC protocol, after a user is authenticated by the IDP, a JWT token is returned, while in SAML, an XML document called a SAML assertion is returned.

Even though SAML is more mature and has more features, for a simple identity-based authentication solution, OIDC is becoming more popular in the space due to the ease of handling JWT tokens when compared to XML documents.

These tokens contain the identity information of the user, and handling them in a secure manner is therefore critical. Since the organisation emphasizes simplicity, security, and functionality for any feature that is developed, adopting the OIDC protocol for their SSO integration would be an obvious choice as it helps setup a simple authentication system using a quick integration.

Firebase Integration Made Easy

The goal of this section is to simplify your SSO integration using Firebase. At a high level, the development team has to:

  1. Setup the team’s Firebase account and configure a project.
  2. Develop the frontend code base for IDP integrations using Firebase.
  3. Develop the backend code base to verify access tokens provided by the IDP.

Setting up a Firebase Project

Firebase has made it really simple for developers to set up an SSO integration project. The steps below show how to complete the setup in no time:

  1. Log in to https://console.firebase.google.com/ using your organisation credentials.
  2. Create a project and enter the necessary details for the initial setup of the project.
  3. Share the API key and authDomain with the front-end team, which will be used for the front-end SDK.
  4. Enable the authentication service and add the necessary sign-in providers (e.g., Google).
  5. Setup resource location as per compliance requirement, and add a name for the app.
  6. Setup API key restrictions for the API key. To do so, follow the below steps:
  7. Go to https://console.cloud.google.com/apis/credentials.
  8. Choose the API key that was created.
  9. Add HTTP referrers as the Firebase app’s auth domain and the organisation’s app domain.
  10. Change the application to PROD mode in settings.
  11. Add Google APIs as allowed in the identity toolkit ONLY.

Follow this checklist as well to ensure all the right practices are followed.

Steps for Frontend Integration

After completing the setup process, follow the steps below to complete your front-end integration:

  1. Choose one of the available sign-in providers on the Firebase platform that you want to integrate with, each provider has its own unique integration process.
  2. Go to Firebase's website and follow the documentation for the provider you've chosen, for example, Google IDP Integration.
  3. Once the integration is successful, the application's user interface will allow users to utilise social sign-in providers.
  4. The IDPs will return an access token that must be sent to a backend API endpoint for user verification and authentication. This completes the authorization code flow, enabling users to securely access the application.

Steps for Backend Integration

After completing the setup process, follow the steps below to complete your backend integration, which can be done in parallel to the frontend integration:

  1. Create a backend endpoint on your server or server-less application to accept the access token sent by the frontend.
  2. Create a backend endpoint on your server or server-less application to accept the access token sent by the frontend.
  3. Verify the access token using a third-party JWT token library available in the language your server is written in. This list provides a good set of libraries a developer can refer to and experiment with.
  4. Additional checks can be done on the token, and further data can be stored in your application database if required, all of which is explained in detail in Firebase’s backend integration document.

In a Nutshell

SSO integration enhances an organisation’s consumer reachability by providing them with a seamless login experience. Moreover, it improves the overall security posture of the platform, provides verified user data, and decreases operational costs and overhead. Navigating the space of SSO integrations is tricky, but by making well-thought-out decisions, you will be able to make the Firebase SSO integration comfortable and swift.