A developer’s guide to Single Sign-On
The world of Identity Providers (IdPs) is bloated and full of complicated enterprise jargon — a deterrent to many developers who would otherwise find IdPs useful. I’m the founder of Yeep, an Authorization-as-a-Service startup, so I’ve spent the past 6 months reading analyst reports, visiting websites, watching videos, and studying communication protocols on Identity Providers. I wanted to share my experiences and give you a simplified version, from a technical perspective. This article aims to explain (1) what is an Identity Provider, (2) how SSO works, (3)why you should care and (4) how to enable SSO and user management for your application.
The problem with passwords
Authentication is a major component in any commercial application. You need to be able to identify your users. For that reason you typically assign users with a public and private key, also known as “username” and “password”. Problem is that customers are fed up with usernames and passwords.
Imagine an organization of 100 employees (a small company by US standards) using 10 cloud services (again, a small number), e.g. GitHub, Box, GSuite and various custom internal software. Each employee needs to maintain (store and safeguard) their own access credentials. That is 1,000 credentials our fictional organization needs to keep an eye on. Add multiple devices (laptops, mobile phones) and remote work locations to the equation and you can see how managing credentials can become a liability. This is where Identity Providers (IdPs) come in.
To err is human (if you are reading this it’s too late).
What is an Identity Provider (IdP)?
Identity Providers (IdPs), also known as Single-Sign-On (SSO) providers, enable companies to centrally manage user identities. They are nothing more than user directories with two (2) basic features:
- Sign-in once, access everywhere;
IdPs reduce the number of credentials a user needs to maintain to a single username and password (to authenticate with the IdP itself), thus minimizing the attack surface to the company’s data. Users sign-in once to the IdP to access all connected applications. - Provision/de-provision user accounts (for apps supporting the SCIM protocol).
When a new employee joins the company, the IT department can provision their account to multiple cloud services from a single interface. Similarly, when an employee leaves the company, their account can be easily de-provisioned.
How does Single-Sign-On (SSO) work?
There are two (2) fundamental options for an Identity Provider to facilitate SSO:
- Agents on client machines, e.g. browser plugins;
- Software connectors built-in to the applications.
What is this black magic?
Agents on client Machines
The IdP functions as a password manager requiring the user or IT admin to upload their credentials to the IdP platform. Upon user request, the IdP sends the appropriate username and password to the agent running on the user’s local machine. The agent operates sign-in on behalf of the user. All this happens behind the curtain — the user doesn’t need to add their credentials other than submitting them to the IdP the very first time.
Even though this qualifies as SSO, it’s not true identity management. It’s merely a smart way to automate user login. Modern password managers already support this functionality, e.g. 1Password, DashLane.
Worth noting that your credentials are as secure as the agent’s host. At some point the username and password need to be submitted to a web browser in plain text. A malicious user could intercept communications and get ahold of the credentials. This might be undesirable in several cases, so customers should use with caution.
Software connectors built-in to the applications
This is where you, the developer, come in by extending your apps with software connectors. The connectors enable users to sign-in (also sign-up depending on the implementation) via their favourite IdP, such as GSuite or Okta.
Software connectors provide true SSO. Users don’t need to know anything about username and password, except their IdP credentials. They are also more secure than agents, since no credentials are transmitted to the client’s machine.
Why should you care?
Look at all the money
If you are looking to attract big enterprise customers then you need to enable SSO and (preferably) user-management capabilities for your app.
Please note: This is not something you would want to do from day 1 (unless you are 100% enterprise focused). As your app matures, your customers will start asking for it by themselves. You should therefore be prepared and well-informed so you don’t find yourself in a position that you need to rewrite your authentication module from scratch.
The most successful companies have adopted SSO. Have a look at the customers of the two (2) leading IdPs worldwide (according to Gartner Magic Quadrant for Access Management, June 2017): Okta and Microsoft Azure Active Directory.
Worth noting that there’s a network effect in place here, similar to what we see in mobile platforms, e.g. Android and iOS. Developers add SSO functionality to their apps to reach more customers. IdPs benefit from apps supporting their platform — the more apps they can connect with the stronger their value prop to end-customers.
How can you enable SSO for your app?
The first step to enable SSO for your application is implementing a software connector for one of the following protocols:
SAML is older and more widely-used. It’s based on XML and can only work with server-side web applications. OpenID Connect uses modern technologies, such as REST and JWT, and may also be used with client-side applications, such as mobile apps.
Both SAML and OpenID Connect require the IT admin to pre-configure IdP settings with your SaaS. A typical example of such a configuration can be found here. This is generally acceptable and is considered a good compromise between security and functionality.
By implementing a software connector for one (or both) of the aforementioned protocols you become immediately compatible with most B2B IdPs out there. Consumer IdPs are a different story.
Consumer IdPs don’t allow user-management and are mostly useful for consumer applications (e.g. mobile games) or when you want to verify the identity of a user outside a company’s domain. They typically don’t support SAML or OpenID Connect, but implement their own proprietary protocol over OAuth. The most popular consumer IdPs you need to support are:
How can you enable user management for your app?
User management is an excellent addition on top of SSO. It enables customers to manage (i.e. provision and deprovision) users and groups in your application through their IdP. To enable this functionality you need to implement yet another software connector for SCIM.
The biggest problem you might come across is when user management conflicts with your existing business model, e.g. pricing is based on number of users, customer has exhausted all available licenses in his plan and a new user is being requested by the IdP. If you are going to charge by the user, you should consider adopting a pay-as-you-go pricing model.
Also, worth having a think about what happens when a user is member of multiple domains, e.g. a freelance developer working with two companies at the same time. Assuming both companies have an account in your application, how do you handle authentication? Consider applying a multi-tenant architecture to avoid similar conflicts.
Recap
Identity Providers are not something to fear — they are actually your allies. Hopefully you now have a better understanding of the what they are and how they work.
Eventually you will need to add SSO and user-management functionality to your app. It is already considered a hygiene factor for big customers. So better be prepared. Learn the jargon and structure your app in such a way that you can easily connect with IdPs when the time is ripe.
