The challenges when defining an identity strategy

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.