The implication of digital transformation on identity impacted both the enterprise and the consumer market.

But let’s take a step back and start with an overview of the two markets, how they differ, and their relationships with digital identities.

On one hand, we have the consumer market. The term consumer market, in this context, refers to the market that targets internet users. In other words, every time we consume a cloud service from a PC or a mobile (for example, Microsoft OneDrive or Google Drive) or we hit a website, we are in the consumer market. The consumer market includes social networks (for example, Facebook), search engines (for example, Google or Bing), e-commerce web applications (for example, Amazon, Zalando, or eBay), and, in general, everything consumable by a general internet user. In the consumer market, the service targets us, we represent the final user, and, most importantly, we represent the source of revenue. This revenue may come from our money, our data, (which can include both personal information and/or tracking and collecting our behavior on the web), or anything else that can be profitable.

From a very high-level standpoint, the typical objectives that service has on the consumer market are as follows:

• Increase traffic
• Encourage the users to access the service as much as possible
• Get money:
  • From advertising, if the business model of the application is ad-based
  • Increase the transformation rate in e-commerce applications
  • Any other profitable revenue that comes from the product service model

On the other hand, we have the enterprise market, a market where, historically, giants such as Microsoft, VMware, HP, Cisco, Oracle, and IBM competed to sell products to install and consume on top of servers in the customer’s data center. These tech giants targeted the enterprise market by offering products to the IT department of a company. The IT department of an enterprise company, in turn, needed to create services on top of these products to be consumed by the end business. The result is that these tech giants have always been far from the end business; they have always been focused on boosting the internal IT departments of enterprises. This was the enterprise market that we knew until a few years ago.

The advent of the cloud in enterprises took this paradigm a step further. Today, some of these tech giants, such as Microsoft, Oracle, and IBM, have become enterprise cloud providers. They sell Infrastructure-as-a-Service (IaaS), Platform-as-a-Service (PaaS), or Software-as-a-Service (SaaS) cloud services to serve their enterprise customers that don’t need a private data center anymore. Enterprise customers take advantage of cloud services by fueling external business and at the same time boosting internal employees’ productivity. This has an important implication: offloading the IT complexity and data center management outside the enterprise by delegating it to the cloud providers and letting themselves focus more on their core business rather than on IT tasks and data center management.

Thanks to the enterprise cloud, which provides the capabilities of the past with less complexity and, most importantly, the new capabilities of the next generation, the next wave of the enterprise market is being created. Companies are constantly looking for new ways to improve their business with technology. The cloud market is young, and the efforts by the IT giants to onboard new customers (enterprises) at this stage to guarantee long-term revenue in the upcoming years are a top priority for them.

The portfolio of services that cloud providers provide to enterprises is huge. As anticipated, services span from simple servers (virtual machines) to web servers, to container hosting, storage, backup as a service, and much more. Identity providers are another important service offered to enterprises, and this is the core topic of this book.

In the context of digital identities, if we try to compare the consumer market with the enterprise, we will notice something. In the enterprise market, unlike the consumer market, there is a high level of complexity. The reason for that is that companies are supposed to manage their identity services for their employee. Identity, on the other hand, is consumed in the consumer market and managed by identity providers, such as Facebook or Google, just to provide two examples.

This concept has several implications. To properly use identity services, we need an enterprise-grade identity strategy that can simplify the complexity of this wide and critical topic.

The enterprise market and the consumer market are different, but there is one common factor: simplifying the user experience.

On the one hand, we have the consumer market, where the main KPI is to prevent the users who access the service from leaving too soon. The goal is to maximize the time spent on the service and, consequently, the service adoption.

On the other hand, we have the enterprise market, where companies want to maximize their business and improve employee productivity. In both cases, the adoption of a service and the onboarding of new users are important KPIs.

The user experience (UX) is paramount to achieving these KPIs.

When it’s time to develop a service, regardless of the target market, one core item is mandatory: a user-centric approach. We may have heard this phrase many times, so let’s contextualize it to see what it means.

A user-centric approach aims to produce a UX that is tailored to the user’s needs to make interaction easier and improve productivity. When we talk about a user-centric approach, we also mean a service or a set of services that are built around the user. In the Single sign-on section, we are going to talk about the single sign-on (SSO) experience. Having SSO in place has the important benefit of preventing users from logging in with different sets of credentials to the different services: they just need to prove who they are once and everything else, including the ability to switch to a different service, is done transparently from a user perspective.

The concept of the user-centric approach can go even beyond this. The services know the user, and they can even enrich the user details and information together in a distributed way. This reduces the amount of time the user spends; for example, the user may be asked to provide their email address, phone number, and other information that can be instead provided by the Identity Provider (IdP) out of the box. There are two great advantages of a user-centric approach; one is technical and the other is more business oriented:

• Technically speaking, the application can offload some of the logic to the IdP, which results in easier development and maintenance of applications
• In the business area, the users can enjoy a custom experience that can increase user engagement

The following diagram is a graphical representation of services built upon the IdP. These services can be developed by offloading the identity’s business logic to the IdP:

Figure 1.1 – IdP and service relationship

Of course, to implement services that cooperate to facilitate the UX, an enterprise-grade user management system design needs to be done upfront.

To have an idea of a fully user-centric approach, think about consumer services such as the cloud services from Google or Microsoft. Once you are signed in with your @gmail or @outlook email ID, you don’t need to create a new user to manage calendars, maps, emails, or photos; you are the very same entity across all these services, and these services are going to share the details of your interactions to tailor the perfect UX for you across the cloud service. If you ask Google Assistant to remind you about something when you are back home, very likely you don’t need to specify where your home is, so long as this information has been provided to a different service, such as Google Maps. This gives us an idea of the benefits that can be achieved from a user perspective and how productivity can be boosted with this approach.

To summarize, having a user-centric approach means that services are tailored around users to enable them to get the most efficiency and productivity.

Recently, UX has become more and more important as the market understands that it is directly proportional to user satisfaction with the service. As a consequence, a lot of changes in blueprints and best practices have occurred.

The demonstration of this progress is visible every day. It’s pretty hard nowadays to visit a website where we are forced to register as a new user with very long registration forms and many fields that may discourage the end user from finalizing the action and make them leave the service before they even start to use it. This practice was common in the web of the past generation:

Figure 1.2 – Example of a long registration form, which is not so common nowadays

On the web, it is incredibly common to hit a service where part of the user management or the entire sign-up process is outsourced to external IdPs:

Figure 1.3 – Example of an external IdP signup

Outsourcing the onboarding process to an external IdP has been a game changer; it now takes a user a few seconds rather than minutes to register themselves for a specific web service, something that was challenging before OAuth.

The benefits of sign-up/sign-in outsourcing are multiple:

• Decreases the probability of a user leaving the service before they even start to use it
• Avoids asking for too many details from the user during registration for a service, which may raise privacy concerns and increase the probability of the user leaving the service
• Allows the user to spend their time using the service rather than on ancillary activities such as registering or completing their profile information
• Prevents bugs in the registration experience that prevent the user from accessing the service

There is another important achievement that OAuth brought to the world: a new security level for service-to-service communication. We will discuss the technical details in Chapter 4, Authentication Flows, but let’s take a quick look at it in advance with an example. Suppose you are an architect and you need to create a new service for the consumer market. This service is supposed to enable user-to-user communication through web calls, such as Zoom, Microsoft Teams, or Google Hangouts. Let’s call this service Contoso Video. One of the features of Contoso Video is integration with Google Calendar. This integration should enable users to check the calendar so that if User A wants to send an invitation to User B for a call, the Contoso Video service can check on the calendar whether User B is available at that time.

How can Contoso Video check the Google Calendar of a specified user (in our scenario, User B) without having the username and password of the Google account?

Before December 4, 2007, when the first version of OAuth was released, this wasn’t possible. The service that needed to check the Google Calendar of a specified user needed to have the username and password to log in on behalf of the user to Google Calendar.

This is not good from a security perspective for the following reasons, among others:

• Contoso Video is an external service that needs to store the user’s credentials; it can be hacked or could even be owned by malicious people that are gathering the usernames and passwords of users.
• Contoso Video has the username and password of the target account, which results in unlimited control over what the service can potentially do on the account (for example, it can read the calendar and emails, write emails, or even delete the account). The least security privilege cannot be granted.

OAuth has solved this problem in various ways:

• A user can delegate a service (in our case, Contoso Video) to call another service (in our example, Google Calendar) on their behalf, without directly requiring a username and password
• A user can delegate a service to perform only a subset of actions; in our example, User B can delegate Contoso Video to read the calendar only and not perform any further action:

Figure 1.4 – Contoso Video user flow example

For those who are already familiar with OAuth, you should already be aware of how Contoso Video can get calendar details without knowing the password of User B and how this magic works. Further details on how this flow works can be found in Chapter 4, Authentication Flows, where this magic will be explained with technical details.

Before moving to the next step, it’s important to understand, as will be outlined in the rest of this book, that the OAuth 2.0 protocol is generic and does not differ in enterprise and consumer markets from a technical perspective. The general concepts, flows, and protocol behavior are the same because they are based on the very same Request for Comment (RFC6749). What changes is the adopted IdP, which is the owner of the identities, and is, most importantly, one of the core topics of this book: how IdPs implement the OAuth specs and what the advantages and pitfalls of this are.

In enterprises, the concept is quite different as companies will manage digital identities and need to handle the IdP.

The upcoming chapters will describe the considerations the owner of IdP (enterprises) needs to take care of.

As anticipated in the Digital transformation – the impact on the market section, before the cloud era, tech giants dealt with technology within their own data centers. Identity management is not new for enterprises; historically, IdPs such as Active Directory or SiteMinder worked inside the network perimeter of enterprises with protocols such as Kerberos and NTLM.

Having an identity directory in the enterprise is paramount to managing users, computers, and enterprise assets in general that belong to the organization and configuring access to the company’s assets. The evolution of identity in the consumer and in the enterprise led to most IdPs supporting OAuth, and they typically work as SaaS outside the network perimeter of the enterprise (that is, they are exposed to the internet, not the intranet). This has several benefits because users can now log in to the enterprise’s services even outside the intranet and the VPN, improving the company’s productivity. This also brings security implications into play, which will be covered in detail in Chapter 5, Exploring Identity Patterns.

What companies tend to underestimate is that cloud IdPs nowadays take advantage of the OAuth protocol, which is very different from the previous protocols as it takes into account new concepts such as delegation across different services, app registration within the enterprise, and new authentication flows, which, in turn, can impact the way enterprises develop services and APIs.

In an enterprise, user information, identity, and access are managed by the company, which deals with the life cycle of the digital identities of its employees (at a minimum, some companies even host external identities as vendors and/or contractors in their IdP). Companies typically have processes to onboard the employee’s digital identity when hired (provisioning). The identity is then used to enable the user to access the company’s tools, services, and websites and, finally, when the user leaves the company, there is a process to delete/disable (deprovision) the user’s digital identity to prevent unwanted access to company resources.

From our experience in enterprises, we can certainly state that the concept of the user-centric approach is not yet widely adopted. IT departments and project teams are not able to collaborate efficiently with each other while working on projects/apps because they are not organized properly. Sometimes, different teams inside the organization use different IdPs, which makes the user-centric approach complicated. As a result, it often results in a very bad practice of managing user identity consistently. This outlines the importance of an organization having a clear strategy in this domain. As we are going to see in the rest of this book, it’s important to develop a strategy not only to ease the life of the users but also to handle everything that requires authentication, including service-to-service authentication.

If a bad strategy or no strategy is in place, then some applications are even developed without any IdP. When no IdP is used in an application, then the user management feature is usually developed within the application itself with further effort, using independent and custom-developed logic, which is a model that was followed in the past (before 2000) when IdPs didn’t exist at all. When this happens, users need to use a different set of credentials according to the application they need to log in to. This scenario is also known as the distributed identity problem and was common in the early 2000s. The following diagram shows the distributed identity problem:

Figure 1.5 – Distributed identity problem example

The consequence of such a model is having less productivity for the following reasons:

• Users need to remember different sets of credentials
• More lines of code have to be written for an application to handle the authentication logic, typically offloaded to an IdP, which results in increased maintenance and more time to market to develop a single application
• User information is not centralized, which might result in users wasting time enriching their profiling information for each application
• Identity needs to be managed by custom implementations, which may lead to security issues

These are the typical scenarios and the duties an enterprise needs to accomplish to manage its digital identities. If we look deeper, there are important implications for an architect to consider, as we will discuss in the upcoming section.

Every software architect, during the design phase of an application, should carefully take care of the concept of digital identity first.

Authentication and authorization are usually the very first tasks an application needs to perform before triggering any other business logic. This is common to every application that requires authentication within an enterprise.

When architects are working on demand to develop an application without taking care of the surrounding ecosystem, many items could be neglected.

For example, an application under development may have a subset of requirements that can be easily addressed by taking advantage of API logic that’s already present within the company’s portfolio. This simplifies the development complexity of the current application and represents a good practice to increase the company’s efficiency overall. This kind of scenario has many salient points, as follows:

• Companies need to have a well-known portfolio of APIs with good descriptions that can be evaluated before starting any application development
• The API to be taken advantage of needs to already be registered on an IdP with a well-known authentication process that can be consulted by the architects
• The API should be designed to take advantage of the OAuth scope’s capabilities to enhance security within the company (scope is an OAuth spec that will be explored further in Chapter 3, OAuth 2.0 and OIDC)
• The API may be designed to accept requests from two possible actors:
  • The application that calls it.
  • The user who is currently logged in to our application. As such, our application needs to call the API on behalf of the user (the concept of delegation will be explained in Chapter 4, Authentication Flows).

You don’t have to understand what these points mean in depth at this stage. Each of them will be covered in this book; what is important is to have a high-level understanding of the implications that an application design has on a wider ecosystem.

Another example is that an IdP may already have the user information the application needs to acquire. This may have an impact on the user interface and the business logic that needs to be developed.

Another important point to consider is the audience that is supposed to adopt the application under development. An enterprise application can be developed for the customers of the company, for the internal employees, for third-party companies, for a partner, or a combination of them all. This can affect the choice of IdP for the application before the development and for every scenario. It is advisable to identify the options architects can choose from in advance. Not pondering all the IdP options in advance can lead to anarchy or bad architecture, such as having multiple IdPs for the same audiences and purposes. In other words, don’t provide clear IdP options to handle digital identities for specific audiences; it will lead to chaos, which is what many companies are suffering from today.

It is also important to spend a few words on anonymous web applications as they are usually still part of a company’s application assets.

Anonymous web applications are available to every user without any awareness of who the caller is from an application standpoint. Anonymous web applications were very common in Web 1.0 when the internet was based on static websites with little or no server-side logic. Anonymous web applications, by definition, do not require any user authentication. The scope of an anonymous web application was usually to showcase a product or a service to the end users and, in many cases, was handled with poor or no server-side logic. This is because the page that was served to the client was typically the same for every request.

If you are thinking that anonymous web applications do not need to consider authentication and authorization during the design phase, it’s important to note that this is wrong. Anonymous web applications do not require any user authentication but can still interact with APIs and with the company’s assets and, as such, they may need to have their own identity within the enterprise in the same way as authenticated applications. This concept will become clear in the rest of this book when we describe OAuth flows and application registration in Chapter 5, Exploring Identity Patterns.

In the upcoming sections, we are going to tackle this topic more deeply from a technical perspective. We are going to introduce the most relevant identity protocols and technologies adopted within enterprises to lay the groundwork for the rest of this book and to present OAuth 2.0 in Chapter 3, OAuth 2.0 and OIDC.

When we talk about authentication, it is practically impossible to not talk about SSO. Everybody has found themselves stuck with different definitions of SSO, but how can we define it and understand in detail exactly what this term means and implies? SSO is an authentication capability that allows a user to not insert their credentials every time they need to access an application. SSO should not be confused with saving your credentials within a web browser when prompted to do so when logging in to a web application through a web form. SSO is more subtle and involves the interaction of different actors that contribute to preventing the user from being asked for their credentials when moving from one application to another.

To make SSO work, a user should provide an application with proof of authentication, which certifies that the user has already been through an authentication flow. The application, on the other hand, should trust this proof of authentication, which should contain enough information to make the application decide whether user authentication can be skipped entirely.

How is it possible to achieve this? This is where the federated authentication protocols lend a hand; they will be discussed in greater detail in the following chapters.

For now, it is important to understand that to implement SSO, the following components should usually be involved:

• A common authentication server: For different applications to trust the same user’s proof of authentication, a common authentication server must be put in place. Applications must not manage user credentials directly, but they have to delegate authentication to an external server.
• A common language and message format: Messages between applications and the format of the proof of authentication should be standardized to make integration and interoperation among applications easy to implement. This is usually the job that’s done by authentication protocols, which will be discussed later in this chapter.

Very often, there is a common authentication server (also known as an IdP), which takes more than one authentication protocol and can create a proof of authentication that’s suitable for every trusting application, regardless of the language (protocol) required by each of them.

Let’s examine an example. We are going to mention several protocols that will be discussed in detail in the following chapters. For now, the only important thing to know is that each protocol has a way of formatting exchanged messages and proof of authentication.

There is a user who needs to access two applications that trust a common authentication server. This authentication server can either store and manage the user’s credentials directly or delegate credential validation to an external system. In this example, let’s assume that the user’s credentials are directly managed by the authentication server. The user tries to access the first application, but since they don’t already have proof of authentication, they are forced to go to the authentication server first to obtain it. Once it is obtained, they can return to the first application with their proof of authentication and get authorized to access it. Now, let’s suppose that the user would like to access the second application. The user cannot generally use the proof they already have for the second application and therefore they need to go to the authentication server again to obtain proof of authentication that is valid for it too. This time, the authentication server does not require the user to insert their credentials again because they have already done so, and therefore it just issues new proof of authentication for the second application. This happens because the authentication server, during the user’s first successful authentication attempt, established a session with the user, meaning that it saved a state representing the interactions that the user had with it. The user can therefore access the second application without re-entering their credentials: they SSOed into it. A couple of things are worth noting here:

• Each application could potentially use a different authentication protocol with the authentication server
• The authentication server is how SSO happens; it is in charge of recognizing a user’s identity by looking at the session information the user established with it during the authentication process

SSO has greatly simplified the UX during the interaction with different applications by reducing the user prompts for credentials. This behavior has several implications, though, some beneficial and others detrimental. On the positive side, the less a user is asked for their credentials, the less they are susceptible to phishing attacks (which require the user to insert their credentials on a malicious login page). The user may wonder why they need to insert their username and password again and why SSO is not working as expected. On the negative side, having one set of credentials means that if they are compromised (or if the proof of authentication is stolen), then an attacker may get access to multiple applications since they all rely on the same set of credentials or trust the stolen proof of authentication. Using MFA and advanced security capabilities prevents most attacks related to SSO scenarios.

When most applications used to have user databases/repositories, an effort was made by several companies to create standard ways to centralize user information and details in common places. For the users, this would have meant not needing to remember passwords to access each application anymore.

In the 1980s, telecommunication companies introduced the concept of directory services into IT. A directory service was a central place where all the entities that made up a network were represented and given a name. Directory services were introduced as an Open System Interconnection (OSI) initiative to find common network standards to enable interoperability among different software vendors. This made a standard necessary, and this is one of the reasons why the x.500 directory service came into the world and subsequently the Lightweight Directory Access Protocol (LDAP) as the means to authenticate a user and allow them to access the objects within a directory. The term lightweight in LDAP was introduced to highlight how it differed from the former DAP protocol: LDAP was based on the TCP/IP protocol stack, which highly simplified the access to x.500 directories.

LDAP was great at centralizing information and making it available to end users and applications. However, it wasn’t that great at making collaboration between different directories easy. Having a single directory with all the network users and objects is not easy to achieve, even within the same company. Different business units and areas might have different needs in terms of security and segregation, and they very often do not want to risk that a user without the proper authorization may access restricted and sensitive assets. Luckily, the Massachusetts Institute of Technology (MIT) developed and published the Kerberos v5 protocol in 1993 to protect network services through authentication and authorization of users and applications (versions 1 to 3 were internal to MIT, and version 4 was published in the 1980s).

As an authentication protocol, Kerberos introduced several new innovative concepts:

• SSO: The Kerberos Foundation is about ticket exchange. Successful authentication for either a user or a computer (which is a separate entity) will issue proof of this authentication by an authentication server in the form of a ticket. The authentication server component that oversees the issuing of tickets is known as the ticket-granting server (TGS). An authenticated entity can therefore use this ticket to prove they are who they claim to be and, consequently, request authorization from other entities who trust the same Kerberos authentication server. This process involves other tickets being issued by the TGS – generally, one for each service an entity requests access to. Once, for instance, a user has been authenticated and receives their ticket from the TGS, they can then access different services without being required to insert their credentials each time. They can use their ticket to SSO into other services, so long as the ticket has not expired (in that case, the user must re-enter their credentials).
• Realms and cross-realm authentication: Kerberos also introduced the important concept of realms. A realm is a domain where a Kerberos authentication server is allowed and has the authority to authenticate a user, a service, or a computer. When it comes to a complex organization with different business areas and independent administration requirements, then it is very likely that more than one realm should be put in place. What is the difference from LDAP, then? Kerberos introduced the concept of cross-realm authentication, where a TGS in a realm trusts tickets issued by the TGS in another realm by creating a sort of trust relationship between Kerberos realms. This quite simple concept enabled new use cases that were impossible to achieve before, such as the highly sought-after collaboration between different business unit realms within the same company.

It is worth mentioning that, at the beginning of the new millennium, Microsoft introduced both LDAP and Kerberos as standard authentication protocols in one of its iconic products, Active Directory. Active Directory has been, and it is still today, the foundation of authentication and authorization for most enterprises. But nowadays, its success is also the main IT professionals’ pain in the neck when it comes to shifting that paradigm (which was great in the early 2000s) to a more modern authentication approach.

Everybody remembers that the end of the 1990s was also famous for the advent of a revolution in the IT world. We are talking about the rise of the global internet, known as Web 1.0 – that is, commercial use of the internet on a global scale. This important transition brought with it a higher demand for collaboration between companies where businesses had to interact with other businesses more and more, expanding their horizons on a global scale to avoid being cut off from the great innovation that could overwhelm them in the blink of an eye.

In that era, Kerberos and LDAP could not enable this new type of collaboration; their capabilities were not suitable for making users, services, and computers interact when such services were managed by different legal entities.

The reason why Kerberos wasn’t ideal to be used over the public internet wasn’t related to the security of the protocol but rather to its authentication model, which didn’t easily fit the needs of most public internet applications due to its complexity. Try to imagine the distribution of the keys required by the protocol to all the machines used by end users to access a website. LDAP, on the other hand, would need to import the users of our company into all the LDAP directories of those external organizations that publish a website that we would like to get access to. The larger the number of organizations involved, the greater the complexity of making collaboration work.

It was time for a different way to manage authentication; it was time to introduce the concept of federation.