Wisdom is not a product of schooling but of the lifelong attempt to acquire it.
—Albert Einstein, theoretical physicist, from a letter dated March 24, 1954
Throughout our experiences helping customers implement identity management solutions for their applications, we have seen two common paths that lead a company to focus on identity management-related issues. In many cases, this focus even leads to a dedicated identity management division or project within the company.
Some companies quickly recognize the challenge and build identity management as a component separate from their applications from the beginning. This is common in larger organizations starting new projects, often after they have experienced significant challenges. Another common pattern we have observed is an organization taking a reactive approach, usually triggered by having to resolve blockers in product sales, reduce unexpected downtimes, solve challenges associated with continuous investment of time and effort required for building and maintaining identity management services, or, in the worst case, having to face identity-related crises like data breaches that need immediate attention.
On both paths, we have often seen application developers start by cataloging a laundry list of to-dos involving what the user journeys such as sign-up, login, and account deletion should look like, what account management and analytical requirements are needed, if multi-factor authentication is required, and so-on. There is an expectation for all of this to work smoothly across multiple devices, several versions of browsers and operating systems, all while satisfying many constraints in terms of user experience and of course cost.
The result is usually an identity service built using in-house engineering and DevOps teams, often with commodity off-the-shelf or open source tools. As one or more applications connect to this service, it quickly becomes obvious that this identity service needs to be fault-tolerant and highly available, to avoid becoming a point of failure for the applications. It also needs to be secure and protect user data against many types of attacks.
Over the course of time, the teams maintaining the in-house identity service start to feel like they are fighting a Hydra – the mythical beast from Greek mythology with nine heads. When any one of her heads was cut off, two more grew back in its place. In the same way, solving one identity management challenge can give rise to more without a well-planned strategy.
In this book, we’d like to give you a high-level introduction to identity management and provide you with as much knowledge as we can to better equip you on your quest toward delivering successful identity management in your application and avoiding a Hydra.
Identity Challenges
While identity management may initially seem to require little more than a form with a username and password, many factors need to work together for it to work well in practice. It requires careful planning, design, and development to implement identity management for an application while balancing the myriad expectations stemming from business requirements and security, not to mention the need to provide a great user experience.
Unfortunately, identity management isn’t a one-size-fits-all proposition. There isn’t a master solution we can provide that fits every use case. However, we believe that our combined experience may help you navigate through the landscape better, equipped with an overview of the challenges that you’ll face ahead.
As an example of these challenges, here are a few of the most common decisions to consider when developing your applications.
Who Are Your Users? And Will They Authenticate?
A consumer using an app on their phone to book a restaurant will probably want the ability to log in quickly, perhaps using an existing identity like Google or Apple, often referred to as social logins. Users may even expect to use more than one way to authenticate and still be recognized as the same person. We have seen this happen often as a result of a user forgetting the original “account” they signed in with, resulting in confusion and a drop-off in application usage because users can’t remember how to log in.
Employee users of an application at their workplace want easy access via a single work account. This is usually referred to as single sign-on, enterprise federation or enterprise login. For an increasing number of organizations, this is a mandatory requirement when purchasing a workforce application.
You may also encounter requirements to offer passwordless authentication or username-password authentication for first-party accounts that are stored in your system.
Level of Authentication Strength
Which authentication mechanisms will adequately protect your application? It depends. An application with sensitive content like a banking application is a clear scenario where you’d want to ensure you know who the user is, in the most secure way possible. For other, less sensitive, applications, you may need to determine how to provide adequate security while still being convenient for users.
There are many options to consider for authentication. Today, the most common means of implementing authentication are based on something the user knows, such as a password. While passwords provide basic security, they are prone to being stolen. For more secure applications, there are additional means to verify a user’s identity, which may be used on their own or with a password. These strategies typically rely on something the user possesses like a one-time password generated on a device or a hardware security token with a cryptographic key. Alternatively, other approaches rely on who you are, leveraging biometric scans or user behavior, such as typing, to authenticate a user. You need solutions that are easy for users to adopt and use because cumbersome solutions may result in users circumventing the solution or simply abandoning the application entirely.
Unfortunately, your problems don’t end once the user is authenticated. After authentication, a user’s password may be compromised or their authentication device stolen. Applications need to accommodate for additional threat vectors, such as authentication tokens being lost or stolen, credentials being breached, and scripts that mimic user activity in order to brute-force their access into user accounts.
Simplifying Access for Users
How do you provide simple but secure access for your users? Your users will likely want single sign-on so they can log in oncei and access their account at multiple applications easily, such as your application and your application’s support center. Single sign-on provides convenience to users, but it is also considered great security hygiene as it offers a single place to control authentication policy, reduces the number of passwords that users have to remember, and allows you to focus efforts on simplifying identity.
It is important to keep in mind that authentication requirements will often change depending on the platform or device the user is using to access your product. Authentication on the Web is very different from apps running on a smartphone or a Smart TV. It can be even more different if you want to support devices like Alexa. Identity management can easily become a limiting factor if your solution does not accommodate the possibility of easily supporting diverse future platforms and devices for users.
In addition to authenticating users, your application will also need to enforce access policies. For some applications, such as a platform to stream movies, access policy may be simple, based solely on whether a subscription fee has been paid. For other applications, such as enterprise systems for manufacturing and inventory control or sales management, access policies can become complex and might need to take into account a user’s profile attributes, the time of day, the method of authentication used, and the specific data involved.
Migrating Users from Legacy Applications
Will you need to migrate any existing user accounts from elsewhere? A part of simplifying access is the integration challenge if you need to migrate users from legacy in-house applications that have highly specialized user stores and third-party apps like support centers and community forums that also have their own user stores. Mature legacy application projects may offer a means to connect single sign-on, but in other cases, it is largely left as an open problem to solve for the application builder, with minimal support for industry identity standards like SAML, OAuth, or OpenID Connect.
The migration of existing users from legacy user stores, however, is not covered by those standards and is often a very time-consuming and expensive process to solve. This involves migrating existing users along with their credentials, merging duplicate users in a secure manner, ensuring uptime for the existing applications during the migration, and migrating some apps while ensuring other systems can stay in place. This is a challenging part of many identity projects and can severely impact the likelihood of success due to scope creep!
Regulatory Requirements
How will you satisfy regulatory and compliance requirements? Privacy is a hot topic among developers, companies, and legislators. Modern users are concerned about identity data breaches, identity theft, and about being continuously tracked, in many cases without their consent, by third-party marketing analytical websites. These issues raise several ethical and technological challenges.
Many governments see the privacy of their constituents as a fundamental right and have been working on regulations for the handling and protection of sensitive identity data. These are topics of increasing interest among global legislators. With legislation like the GDPR (General Data Protection Regulation) in the European Union, California’s CCPA (California Consumer Privacy Act), and similar legislation being drafted, debated, and enacted in many jurisdictions, applications that collect or process user data must comply with privacy requirements, as noncompliance may incur severe penalties in the event of a breach.
User Experience Constraints
How do you create a good onboarding experience for your users? Bad identity decisions can negatively impact a user’s perception of an application. Imagine you just installed a brand-new application to look at pictures and the sign-up process asks for a scan of your passport and a selfie video. This would doubtless seem a bit suspicious because it’s hard to imagine why a picture browsing application needs your passport information. A bad sign-up and login experience can hurt the usability and adoption of your application. On the other hand, for a financial application, the need to provide a passport for identity validation would seem more reasonable. Recording a video to verify your identity is, in fact, part of an innovative onboarding experience for a challenger bank application like Monzo.ii
The challenges outlined here are just a sample of what you may face in designing identity management for your application. Additional challenges involve when and how to collect user profile information, how to manage user sessions, and even what to do when a user logs out. The design of identity management for your application needs to answer all these questions and more while considering the sensitivity of your application and satisfying all the relevant business and legal requirements. You’ll need to weigh different approaches and design for a user experience appropriate for your application’s delivery platforms.
Objective
Our objective in writing this book is to provide you with an introduction to the topic of identity management, based on our experience building and deploying applications. The focus is particularly on aspects of identity management for software applications, such as creating accounts, authentication, API authorization, single sign-on, account management, logging users out, and deprovisioning accounts. To set realistic expectations, identity management is a huge topic. One book cannot make you an expert or cover everything there is to know. The specifications for the identity protocols we’ll discuss total over 800 pages, and they represent only a portion of the information that you need to know. We cannot hope to cover every aspect of these protocols or every identity management use case. What we can reasonably do is provide an introductory overview that helps you understand common aspects of identity management needed by a typical application project, how three standard identity protocols solve basic use cases for you, and how a sample program solves some real-world scenarios.
We will cover three popular identity protocols, namely, OAuth 2, OIDC, and SAML 2 – specifically, what problem each is designed to solve, how they work, how to implement authentication and authorization requests for simple cases, and how to troubleshoot issues. We can’t cover every parameter or use case, but you should get a basic understanding of what each protocol does and how it works. We hope the text and sample program that accompanies this book give you a helpful overview of identity management for your application development projects. We also hope you are inspired to explore this topic further to learn about more advanced use cases and solutions.
Appropriately designed, an identity management solution can simplify your overall architecture. It can allow your application to delegate some identity-related responsibilities to other components, and it can provide a single view of the user and unify access control to simplify access issues, provide critical auditing capabilities, and more.
We’ve organized the content around the events in the life of an identity. We start out with a discussion of account provisioning and several options for getting users set up so they can use your application. Then we dive into API authorization and authentication and provide an overview of three popular protocols in use today, namely, OAuth 2, OpenID Connect (OIDC), and Security Assertion Markup Language (SAML) 2. These chapters cover authenticating users and handling authorization for applications and APIs. After covering the basic mechanics of the protocols, we have a chapter that explains the sample program that accompanies this book and how it uses these protocols.
The subsequent chapters cover additional scenarios, with introductory information about single sign-on, stronger forms of authentication, account management, logout, and deprovisioning. In case your application doesn’t work perfectly the first time, we’ve included a chapter with guidance on troubleshooting. We’ve also shared information on problematic scenarios that may arise and some more unusual use cases we’ve come across. We close with a quick overview of compliance as well as some mistakes that have led to some very unfortunate breaches.
We recommend reading the chapters in order, at least through Chapter 15, as many of these chapters build on previous chapters. For the rebels in the crowd, we especially recommend at least reading Chapters 4 through 10 in order as they have the most dependencies on earlier content. The chapters after Chapter 15 can mostly be read in any order. Chapter 16 on troubleshooting will be most relevant when you need to debug an issue. Chapter 18 on less common requirements might be valuable to read early on in a project as it may help you identify items to include in your project plan. Chapters 17 and 19 cover different types of issues and will help you plan for, or avoid, many mistakes.
In the chapters on OAuth 2 and OIDC, we’ve provided samples of HTTP requests to be made by an application. We realize you may use a library or SDK to facilitate such calls, and in fact we heartily encourage this. If so, the call syntax will differ for your chosen implementation. However, while every library or SDK will be different, the underlying calls should be in alignment with the standard specifications. When it comes time to troubleshoot your implementation, you’ll likely use a browser tool or debugger to analyze the calls made, and at that point, an understanding of the underlying HTTP requests such as we’ve shown in the book will be useful. Even if you are merely configuring a purchased application, an understanding of the basic requests and responses will be of benefit for troubleshooting.
One note about naming is in order. The protocols we cover have each used different terminology. This makes it difficult to use consistent terms for certain components. We debated between several approaches and finally decided that in a chapter discussing a specific protocol, we would use the terms used by that protocol, and in other chapters, we would use more generic terms. For example, in the OAuth 2 chapter, we refer to an authorization server; in the OIDC chapter, the OpenID Provider; and in the SAML 2 chapter, the identity provider. In the other, more general chapters, we use the term identity provider for a service that authenticates a user for an application. One exception is in our term for a client application. There are many names for a client application across these protocols – client, relying party, service provider, client application. The terms client and relying party mean different things in some specifications. To reduce confusion for beginners, we’ve chosen to use the term “application” throughout to refer to an application making authentication or API authorization requests via OAuth 2, OIDC, or SAML 2. This is not ideal as it ignores the fact that in more involved use cases, OIDC and SAML 2 clients may not be applications but rather can also be providers to other clients. Since our focus is on introductory, basic use cases, we decided to make this trade-off for the sake of simplicity and consistency across chapters. We occasionally use the term relying party where the entity referenced is a relying party which could in turn be an identity provider serving other clients rather than a simple application. We also refer to end users as simply users, as we don’t need to differentiate between types of users.
A note on versions is also in order. Since the original publication of this book, there has been additional work on OAuth, resulting in the OAuth 2.1 framework specification document. This edition of the book is aligned with the recommendations made in the current draft of OAuth 2.1, and the versions of OIDC and SAML 2.0 published at the time of writing. For the sake of simplicity, we will refer to these identity protocols as OAuth 2, OIDC, and SAML 2, unless we are referencing a particular version of a specification document or a document title.
Sample Application
To complement the text, we’ve provided a sample application that uses the OIDC and OAuth 2 protocols. Chapter 10 explains the sample application and how it was designed to use the identity protocols as part of an identity management solution. We need to give the usual caveat here. As sample code, the code samples in the book and sample application omit various functions for the sake of simplicity. They are not production-ready code and should not be used as a basis for production applications.
Design Questions
Who are your users: employees, consumers, or a business?
How will users log in? Is there an existing account available to them that they would like to reuse?
Can your application be used anonymously or is authentication needed?
What kind of delivery – Web or native – does your application intend to provide?
Will your application need to call any APIs? If so, who owns the data that your application will retrieve?
How will your application interact with APIs, both public APIs and your trusted subsystems?
How sensitive is the data that your application handles?
What access control requirements are needed?
How long should a user stay logged in?
Is there more than one application in your system? If so, will users benefit from single sign-on? (Don’t forget a support forum!)
What should happen when users log out?
Are there any compliance requirements associated with this data?
Summary
Modern users expect a frictionless, well-designed experience when using an application. Identity management should help them access an application quickly, not get in their way. In order to achieve that, developers face a lot of questions and need to sort through a wide range of options available to them when developing identity management solutions for modern applications. The next chapter will help you understand the components of an identity management solution by covering the events in the life of an identity.
Key Points
Identity management poses many challenges to developers of modern applications.
Identity management solutions must be appropriate for the sensitivity, desired user experience, and delivery platforms of an application.
Identity management is a huge topic, more than can be covered completely in one book.
We’ll provide an overview of identity management and typical requirements for identity management for your application.
We’ll cover three protocols – what they are used for, how they work, and how to make a basic authentication or authorization request.
We’ll provide a sample program that illustrates some of the topics discussed.