Identity Challenges

While identity management is a simple concept in theory, 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.

To give you an example, here are a few of the many disparate challenges you might need to think about. A consumer-facing application may have users who expect the ability to log in quickly using a social provider like Facebook. They may even want the ability to use multiple social providers to log in to your application and still be recognized as the same person. You’ll want to handle this requirement gracefully, otherwise users might abandon your application because it’s a hassle to sign up and log in. On the other hand, employee users need to access corporate applications via their work account, and they want the convenience of single sign-on. What’s more, corporate organizations typically have complex authorization requirements, often based on roles, to govern permissions for what the employees in the organization can do.

An application with sensitive content might require stronger forms of authentication than a simple password, but this requires determining which forms of authentication provide adequate security while still being convenient for users. There are many options for strong authentication, varying from one-time passwords generated on a device to push notifications sent to a mobile phone or hardware security tokens with private cryptographic keys. 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.

If you offer multiple applications, or even a support portal in addition to your application, your users will likely want single sign-on so they can log in once and access multiple applications. This provides convenience to users as well as a single place to control authentication policy. However, authentication is the gateway to your application. It must be highly available and capable of scaling up higher than your application(s); otherwise, it will suddenly become an obstacle rather than a gateway. Single sign-on is not a benefit if it impedes access to your applications!

Your application design may need to accommodate various constraints from your delivery platform. On the Web, a user may expect a browser redirect to a sign-in page for authentication. In contrast, users of native desktop applications may prefer login flows embedded within the application or leveraging a session provided by the underlying operating system. Different mobile applications may use different approaches. Some may redirect you to an identity provider to log in, but others may still prompt for your credentials directly in the application. You’ll need to weigh the different approaches and design for a user experience appropriate for your application’s delivery platforms.

The design of identity management for your application needs to answer all these questions and more while taking into account the sensitivity of your application and satisfying all the relevant business requirements. An example might help to show how bad identity decisions can negatively impact a user’s experience with an application. Imagine you just installed a brand-new application to look at cat 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 cat picture 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. It might even be driven by regulatory requirements. In fact, recording a video to verify your identity is part of an innovative onboarding experience for a challenger bank application provided by Monzo.ⁱ If you are making a cat picture application, a frictionless social login might be the perfect solution. However, if you are building a banking application, you’ll need a more involved sign-up process and identity validation as well as strong authentication. The identity management solutions for an application must match the sensitivity and type of an application.

As if that wasn’t enough, another major concern when building an application is privacy regulations that govern the handling and protection of sensitive identity data. With legislation like the GDPR (General Data Privacy Regulation) in the European Union and similar legislation being enacted elsewhere, applications that collect or process user data must comply with privacy requirements as noncompliance may incur severe penalties in the event of a breach. The challenges outlined in the preceding paragraphs are just a sample of what you may face in designing identity management for your application.

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, and logging users out. 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.0, OIDC, and SAML 2.0 – 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 come away with 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 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.0, OpenID Connect (OIDC), and Security Assertion Markup Language (SAML) 2.0. 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 what happens after the user logs in the first time, with introductory information about sessions, 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. Might as well learn from the past!

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 9 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 mistakes.

In the chapters on OAuth 2.0 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 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 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.0 chapter, we refer to an authorization server; in the OIDC chapter, the OpenID Provider; and in the SAML 2.0 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.0, OIDC or SAML 2.0. This is not ideal as it ignores the fact that in more involved use cases, OIDC and SAML 2.0 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 be a 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.

Sample Application

To complement the text, we’ve provided a sample application that uses the OIDC and OAuth 2.0 protocols. Chapter 9 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

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.

Note