7

Identity Providers in the Real World

In the last chapter, we saw the most popular trends that describe the challenges that any enterprise architect should be aware of when designing an application nowadays.

This chapter will provide a list of the most prominent Identity Providers (IDPs) that are part of the modern identity landscape. We are going to briefly describe their capabilities in terms of use cases and the target audience they cover.

The objective of this chapter is not only to review the most prominent IDPs one by one but also to enable you to understand, appreciate, and evaluate technical and non-technical considerations when it is time to choose a provider.

We will cover the following topics in this chapter:

• The technical aspects
• The non-technical aspects
• Azure Active Directory (AAD)
• Azure Active Directory Domain Services (AD DS)
• Azure Active Directory B2C (AD B2C)
• Active Directory Federation Services (AD FS)
• Customer Identity from SAP Customer Data Cloud
• Okta (Auth0)

The technical aspects

There are many technical aspects in terms of the choice of which IDP to choose and it is not easy to scrutinize all of them.

We can definitely start with an initial distinction that connects the dots with the initial part of the book when we mentioned how the cloud era is affecting the identity landscape: one of the initial choices is whether to have a hosted IDP or a cloud IDP. By hosted IDP, we mean an IDP that needs to be installed and maintained by the enterprise on its server or in its data center. In this case, the enterprise is responsible from end to end and needs to have a dedicated team to take care of the entire stack. This is a legacy approach and companies tend to use SaaS IDPs in which the service doesn’t need to be installed or updated, as it is part of the purchased service by the specific cloud provider. We’re going to call these kinds of IDPs cloud-based, and there is a clear trend nowadays toward cloud-based IDPs.

Other important factors to consider are the following:

Decision factor	Description
Protocols	As mentioned multiple times in this book, each supported protocol enables a specific type of authentication workflow to be adopted by a specific company. This is usually one of the most important decision factors because protocols such as OIDC and OAuth 2.0 are a must. One caveat here is the way the OAuth specs are adopted and implemented by the IDP. This kind of evaluation may be pushed a level deeper to review not only the protocol implemented but also how close the IDP is to the RFC specs.
Federation	This is the ability of a specific IDP to be federated with another IDP using a protocol or out-of-the-box features such as the ability to invite external users from different IDPs as guests in the target IDP.
Multiple authentication factors	In the cloud era, with fewer network perimeters and more users, greater security depends on how authentication is protected. Having multiple factors of authentication is rapidly becoming a minimum requirement in many companies to enable users to be authenticated not only via a password but also via an SMS, a phone call, an email, certificates, authenticator applications, and other authentication systems.
Client-side libraries	When developers need to write an application that relies on a specific IDP for authentication, the support of the client-side libraries is an important factor. It’s important to note here that many client-side libraries are protocol-based and not IDP-based. There are plenty of IDP-based client-side libraries that take advantage of specific features of IDPs. It’s important that these libraries cover a wide range of coding languages.
Documentation	This is an important factor for all the technology choices, not just the IDP. Having good documentation means providing good support and references so that the developers can write code in a standard way and, most importantly, find answers to common problems. The documentation topic is not only for developers but, importantly, it also needs to be followed by the IDP administrator within the company to find answers and be supported in daily tasks (for example, guiding the registration of an application on an OAuth IDP).
Cost	Although it may not sound like a technical factor, the cost is still relevant because if the cost is low but the maintenance time required to support the IDP within the company is high, a low cost does not imply a better choice. The cost factor is usually a trade-off between the money requirement of the vendor and the overhead the company has to take into account to support the IDP operations.
Support	The availability of the IDP vendor to support the enterprise that chose to adopt a specific IDP is an important factor. This support is generally provided in various pricing tiers according to the SLA the enterprise requires.
Claims	The ability to affect claims before the token is forged by the IDP is typically an important technical aspect that needs to be considered. It is common for an enterprise to require a specific claim to be transformed or injected in order to be read by the final application, which needs to consume an access token or ID token.
API	APIs are usually required, especially by large enterprises, to automate different tasks (for example, application registration or renewing secrets). If APIs are not provided, the tasks need to be done manually, and this could be time-consuming, especially for big enterprises.
Customization	This feature is especially important for enterprises that want to adopt the IDP for their end customers. This functionality includes the ability to perform advanced actions, such as customizing the login screen for specific applications or creating and editing authentication workflows.
Hard limits	Each IDP has a limit in terms of how many users it can support or how many requests per second it can serve. This requires special attention from the enterprise architects, who need to be well aware of the requirements of the organization and the hard limits that can be tolerated for their application portfolio.
Auditing and reporting	Auditing and reporting is the ability to view reports of logins and logouts, enabling administrators to understand how many users access a specific application. One important example in this area is the ability to review suspicious activity: many IDPs raise an alert when, for example, a specific user logs in from the United States, and after a few minutes, the same user logs in from Europe in a timeframe not compatible with an actual relocation, which may indicate hacker activity.
Conditional access	Certain IDPs allow you to grant access to a specific resource not only based on the user identity but also based on what device the user is using, the region the user is connecting from, what their IP address is, or other custom criteria that can enhance the login security.
Provisioning	Users can be provisioned and de-provisioned in multiple ways. The bare minimum functionality is to have a portal that enables an administrator to provision new users. Then, there can be functionalities available via APIs or supported batch processes for onboarding or offboarding users from the IDP.
Self-service	This criterion encompasses all the actions that a user can do on their own without needing an administrator’s help. Examples are self-service password resets (the user in this case is authorized by another factor), profile updates, or any self-management activities that can reduce the workload of the help desk.
Policies	An example of a policy could be a password policy such as configurable account expiration, the minimum number of characters, or the set of characters a password must contain. Policies are a broad concept and an IDP enables the administrator to establish advanced policies to manage it.
Extra features	This table thus far has covered the most typical technical factors of an IDP. Other features include temporary admin privileges, integrations, delegated administration, token signing, token encryption, and access restriction.

Table 7.1 – Technical decision factors

This list should not be considered exhaustive, but at the time of writing, it represents a good reference for the technical aspects an enterprise architect needs to be aware of when they need to choose the identity strategy of their company.

The focus of this chapter will be on IDPs that support modern authentication protocols (for example, SAML, WS-Federation, OIDC, and OAuth 2.0), and we will not cover all the technologies that implement legacy protocols (for example, Kerberos, LDAP, and NTLM), such as AD, based on Windows Server, or eDirectory.

Although many may think that having a standard protocol means that portability among solutions provided by different vendors is guaranteed, this is not always the case. It is actually pretty rare, so developers should know which features are portable and which are not.

Each technology has its own implementation details that make it slightly different from the implementation done by a different software vendor.

Sometimes, these differences do not cause any evident problems, and changing from one IDP to another is smooth and seamless. Other times, this can entirely break the authentication logic of an application in an unforeseeable way.

The most common nuances of protocol implementations within IDPs include custom query string parameters that are not defined in the specifications, custom token formats (JWT has nowadays become the de facto standard format for tokens, which, in the OAuth 2.0 specification, are just defined as opaque blobs that do not have any real meaning for the requesting client), the usage of the user endpoint in OIDC, and, in general, the decision to implement a particular protocol extension defined in separate specifications (for example, the RFC 8628 specification, where an additional OAuth 2.0 flow is defined – the device authorization grant flow).

Knowing the preceding criteria really helps an architect plan an application design because to avoid technological lock-in, they can discern the standard features a specific technology offers and decide whether they would like to create a fully standard application that only uses the capabilities defined in the authentication protocol specifications or not.

This decision is very important, especially when achieving application portability is one of the main goals of the application design.

That said, any of the IDPs we will present has pros and cons in terms of features and capabilities, which are usually not the key drivers for choosing one IDP over another. What happens is that, very often, a specific technology is chosen because of the existing technological footprint an organization already has so that they can harness the technical skills of their people.

This is true for every technology, although choosing a specific IDP has several implications that should be considered at the very beginning so that a comprehensive plan can be defined to overcome any limitations that the IDP might introduce.

Now that we have seen the technical aspects, before digging into the specific IDPs that we are going to cover in this chapter, we are going to discuss the non-technical aspects an architect should be aware of in the following sections.

The non-technical aspects

From an enterprise standpoint, choosing to adopt an IDP depends on many factors. Some of them are non-technical. As an example, regulatory compliance is usually a non-technical factor that can affect the choice of IDP.

An IDP’s adherence to clear business standards, rules, or regulations is represented by its regulatory compliance. There are several reasons why these rules should be implemented. Existing business procedures should be improved, company resources should be secured, customer and employee privacy should be protected, and national and international legal obligations should be met. Customers are more likely to trust a product when it conforms to these laws. They can be sure that the product will perform as expected by the industry and won’t cause them any unexpected trouble.

There are many rules and laws a specific enterprise wants to adhere to and they usually depend on the core business of the enterprise and its location.

One of the most important examples of regulatory compliance you may be familiar with is the International Organization for Standardization (ISO). These certifications aim to establish the highest standards in quality management for proprietary, commercial, and industrial organizations. Another important example that is relevant to many enterprises is System and Organization Controls (SOC). It revolves around protecting financial statements, improving operational efficiency, and maximizing compliance. A third example is the Payment Card Industry Data Security Standard (PCI-DSS). The PCI-DSS usually applies to financial organizations.

If you want to learn more about standards and guidelines, a good source of information can be found in the National Institute and Standards for technology (NIST) documents: https://pages.nist.gov/800-63-3/sp800-63b.html.

The General Data Protection Regulation (GDPR) is another important regulation. It is pretty agnostic to the core business of an enterprise, as it needs to be followed by all European organizations and, therefore, all European enterprises. It was introduced by the European Union to protect the data and privacy of citizens residing in the European Union and the European Economic Area. The GDPR represents one of the most recent regulations, as it was introduced in 2016, and companies that don’t follow it are subject to a fine of up to 20 million euros.

The reason why we wanted to bring these standards to your attention is that choosing a PaaS or SaaS that is managed by third-party companies or IDPs is usually a choice that does not focus only on technical factors. As an example, a SaaS IDP deployed in Europe could replicate sensitive data about its users in the United States for reliability purposes and may fail to comply with the GDPR. In this case, the technical capabilities of the IDP may not be relevant for an organization, even if they are technically better than the competition. This is because a SaaS that doesn’t comply with the GDPR cannot be adopted by a European organization.

Then, there are the technical factors, and these are usually where an enterprise architect needs to step up and support its company for the best choice. There is not one single best choice; it depends on what scenario, level of service, protocols, and technical features a specific enterprise needs to support. During our experience, we have assisted customers who developed multi-factor authentication with custom code on top of the IDP. Recently, this scenario is becoming rare because many IDPs offer this feature out of the box, and a good enterprise architect prefers to focus development on what makes its business unique and differentiated rather than on capabilities than can be maintained by a third party.

When it is time to make a technology choice for an enterprise, business leaders use third-party organizations that offer an independent view of the market landscape and compare the products available on the market. Gartner is one such company, and in this chapter, we want to examine the Gartner Magic Quadrant for access management. It’s important for you to note that the following diagram does not include all the available IDPs. This is because the inclusion criteria for the Gartner Magic Quadrant include many factors that not every IDP can offer, such as support for modern protocols such as OAuth 2.0, session management, profile management, delegated administration, and self-service capabilities:

Figure 7.1 – The Gartner Magic Quadrant for access management

Describing Gartner’s research on access management in depth is beyond the scope of this book, but it is important that you understand the methods and the technical and non-technical factors that can affect an enterprise’s choice to embrace a specific technology and not another. The Magic Quadrant diagram is made up of four quadrants: niche players, challengers, visionaries, and leaders, according to Gartner. The further a technology is to the right side of the diagram, the more complete the vision of the vendor that provides the technology is. The closer to the top a vendor is in the diagram, the better a vendor can execute and apply its technology in the market.

Gartner’s Magic Quadrant is just an example; there are many independent companies that support business leaders in making technology choices, such as Forrester or IDC.

Research by an independent company should be used just as support and cannot replace the judgment and the evaluation of an enterprise architect of a company. It is not rare to see companies that adopt vendors and technology that are in the niche player quadrant of a Gartner assessment. This is because being positioned in an unprestigious quadrant doesn’t disqualify a vendor from consideration. Each technology has specifications, advantages, and disadvantages that may or may not fit the company’s objectives and purposes and the choice should be 100% tailored to these objectives and the business of a specific enterprise.

Let’s now start our journey through the modern landscape of some IDPs.

Azure Active Directory (AAD)

When you encounter Microsoft’s AAD for the first time, the most common (and wrong) idea is to think of AAD as simply the cloud counterpart of AD DS. AAD and AD DS are two completely different technologies that can work together but provide different authentication services. AD DS is a service that comes with Windows Server; it provides an LDAP directory, Kerberos, and NTLM authentication (along with other enterprise features, such as group policy management). AAD, on the other hand, is a modern IDP that doesn’t really know what those protocols are because it implements different ones, such as OAuth 2.0, SAML, WS-Federation, and OpenID Connect.

This means that AAD can be considered a hub centered within Microsoft’s services, as shown in the following diagram:

Figure 7.2 – AAD overview

Any AAD object can be accessed through a REST API called Microsoft Graph, which allows you to create, update, and delete users, groups, and any object type AAD manages.

AAD protects users from credential theft and privilege escalation by greatly increasing the security posture of the overall authentication footprint through several built-in features, including the following:

• Conditional access: Conditional access receives information from different signals during a user’s authentication process to make and enforce decisions according to an organization’s security policies. Signals include the user’s location, the user’s client operating system, the client applications used, and many other things.
• Identity protection: Thanks to the large number of signals Microsoft receives every day in its cloud systems, identity protection provides continuous protection against modern identity threats by constantly learning new attack patterns. Users and sign-in attempts are classified with a risk level (low, medium, and high) together with recommendations that suggest actions to mitigate the risks.
• Identity governance: Identity governance allows an organization to perform the following tasks:
  • Govern the identity life cycle
  • Govern the access life cycle
  • Secure privileged access for administration

This is achieved using entitlement management and access reviews. Entitlement management allows us to create a pre-defined set of applications and permissions that a specific category of users typically needs. These users can then request these entitlements (or access packages) through a self-service portal. Access to access packages can be continuously monitored through access reviews, which are scheduled events that ask the owner of the applications included in an access package to validate or revoke the permissions that have been granted to the user.

• Privileged Identity Management: By implementing the principles of least privilege and just-in-time administration, Privileged Identity Management protects an organization against privilege escalation and lateral movement attacks by not assigning permanent administrative roles. Administrators can choose the role that is most appropriate to perform a specific task and set the amount of time they need to have this role. An administrative role request can also be controlled by an approval workflow where multiple people can decide whether the request is legitimate or not.
• Managed identities: A managed identity is an AAD-specific type of service credential that can be assigned to Azure (Microsoft’s public cloud) services. The strength of this identity type is that the password is not visible to the users that would like to use it because it is automatically rotated by AAD without the user’s intervention. This solution greatly reduces the attack surface because, for instance, a developer using this kind of identity does not have to write the password anywhere and instead, just uses the identity to access whatever resources they have been authorized to access.

It’s worth mentioning that AAD and several other IDPs are gradually inserting the possibility to use other standard ways of authentication, such as OATH tokens (which must not be confused with OAuth 2.0!), compliant devices with FIDO2 technology, and passwordless authentication, which, as the name suggests, removes the password from the authentication process by replacing it with other authentication mechanisms, such as something a user has, a user is, or a user knows.

AAD provides integration with on-premises AD DS installations by allowing the synchronization of the users belonging to such installations with its own user repository. This greatly simplifies the migration of on-premises authentication systems and enables the concept of hybrid identity, as discussed in Chapter 2, The Cloud Era and Identity.

If AAD mainly serves the authentication of an organization’s employees, on the other hand, it also enables Business-to-Business (B2B) collaboration and Business-to-Consumer (B2C) scenarios by allowing several types of external users to seamlessly access applications that are federated with AAD. A lot of enterprise applications already support AAD as an IDP, and they can be integrated directly through the AAD application gallery for user authentication and to enable user provisioning scenarios to and from the aforementioned applications. AAD implements the System for Cross-domain Identity Management (SCIM) protocol to offer a solution for users, groups, and roles provisioning HR systems and end user applications. All these capabilities fall under the umbrella of identity provisioning, another topic we discussed in Chapter 2, The Cloud Era and Identity:

Figure 7.3 – Identity and access life cycle example

It is also important to mention that in order to use Microsoft applications such as Office 365 and Azure, having an AAD tenant is mandatory.

Azure Active Directory Domain Services (AD DS)

Even if AD DS is not an IDP that provides modern authentication capabilities, it is worth mentioning it because of its integration with AAD. AD DS is a managed service that relies on AAD identities to provide a managed AD DS installation (that is, managed Domain Controllers servers) in the cloud. It offers all the basic capabilities that AD DS offers by deploying a pair of Domain Controllers within a private network (an Azure Virtual Network) created through the Microsoft public cloud, Azure. As the non-managed counterpart service that can be deployed through Windows Server, AD DS provides Kerberos, LDAP, and NTLM authentication and simplifies all the lift-and-shift migration scenarios that involve tasks such as moving on-premises workloads (file servers) to Azure. AD DS does not provide the level of customization that a full installation of AD DS offers (the AD schema cannot be extended), but it has been designed for specific use cases that are typical of cloud migration initiatives where velocity and simplicity are key to success.

Azure Active Directory B2C (AD B2C)

AD B2C is a separate Microsoft offering that provides a dedicated AAD tenant with additional capabilities tailored to specific use cases that mainly involve interaction with the customers of an organization. In other words, AD B2C is a Customer Identity and Access Management (CIAM) solution that enables an enterprise to effectively engage with its customers.

In the following diagram, we can see how AD B2C integrates with a heterogeneous group of external systems and acts as an identity orchestrator that can hide the complexity of where those systems are, which language they support, and what type of users they manage:

Figure 7.4 – AD B2C overview

AD B2C offers most of the core AAD features and adds the following capabilities on top of them:

• User flows: A fully guided experience that allows us to create different flavors of flows that guide the interaction of a user with the AD B2C tenant during scenarios such as sign-up, sign-in, profile edit, and password reset. User flows are entirely configurable with a UI but provide limited functionality when compared to custom policies that can be created through the Identity Experience Framework (IEF).
• IEF: A highly customizable framework that can be used by means of a meta-language based on XML files to create custom policies.

Custom policies are configuration files that specify how an AD B2C tenancy behaves. For the most frequent authentications, user flows are specified in the AD B2C portal; however, custom rules may be fully customized by an identity developer to handle a variety of duties. A custom policy orchestrates the interaction between entities in standard protocols, such as OpenID Connect, OAuth, and SAML. To expand the capabilities of these protocols, a custom policy can also interact with generic external systems that expose a REST API to exchange claims. The whole flow defined in a custom policy is dubbed the user journey and is made up of sequential steps. Each step receives some claims as input and generates some claims as output. Each step invokes an entity called a technical profile, which embeds the logic to interact with a specific standard protocol or external system.

A custom policy is managed as one or more XML-formatted files. These XML files refer to each other hierarchically. Within the XML, there are elements that define the building blocks, the interaction with the user, other parties, and the business logic:

Figure 7.5 – AD B2C holistic overview

Compared to an AAD tenant, AD B2C is equipped with built-in tools that simplify the integration with external IDPs by the means of standard protocols. The list of these external IDPs is constantly changing. At the time of writing, it is possible to natively integrate with Apple, Amazon, Facebook, Twitter, Google, and LinkedIn, among other things. AD B2C can also integrate with generic IDPs that implement SAML, OAuth 2.0, and OpenID Connect from their end.

Getting familiar with the language and syntax of a custom policy and the IEF can be cumbersome and discouraging at the beginning, but in the end, mastering it will give you access to a comprehensive set of tools that can change the way a customer engages with all the services offered by an organization.

Active Directory Federation Services (AD FS)

Historically, AD FS has been Microsoft’s solution to federated authentication. AD FS tightly integrates with AD DS by acting as a sort of protocol translator that allows federated applications to use modern protocols, while, under the hood, actually authenticating the users against AD Domain Controllers through Windows authentication (Kerberos or NTLM) without the application being aware of where the user’s credentials are stored.

The infrastructure of AD FS is very simple and is made up of a pair of server roles: AD FS servers and AD FS proxy servers. The former are installed within a company’s internal network and provide their functionality, including single sign-on (SSO), to users connecting from within the organization premises or connected through a virtual private network (VPN). The latter are typically installed in a demilitarized zone (DMZ) network, which is logically separated from the internal network and usually has stricter network rules because of its role as the entry point into the corporate network from the internet.

The following diagram represents a typical AD FS infrastructure architecture:

Figure 7.6 – ADFS architecture

ADFS comprises several features that allow you to customize a user’s (and sometimes a device’s or a service’s) authentication experience:

• External attribute stores: Through a set of built-in connectors, AD FS can augment the claims issued in a token. These native connectors provide integration with LDAP and SQL Server external systems; however, it is also possible to develop a custom Dynamic Link Library (DLL) to integrate with potentially any type of external attribute store, such as a REST API.
• Claim provider trusts: A claim provider trust represents an external IDP to which AD FS can delegate the authentication. A claim provider trust can be an authentication system that “speaks” SAML, WS-Federation, or LDAP. AD FS receives the claims from the IDP and can either relay them to the application as they are or manipulate them according to the application’s requirements.
• Multi-factor authentication: AD FS can integrate with external multi-factor authentication systems to strengthen the authentication process. AD FS natively allows you to configure certificate-based authentication: user credentials are validated by challenging the user’s browser session with a request to provide a valid user certificate that was previously installed on the user’s device by their organization. A user certificate installation is typically done by means of a Group Policy through AD (if it’s a Windows device) or by web enrollment services that implement the Simple Certificate Enrollment Protocol (SCEP).
• Custom claim rule language: Thanks to a built-in claim rule language, AD FS can manipulate the information that needs to be sent to an application within the security token. Claims can be augmented, transformed, merged, deleted, or issued only if specific conditions are satisfied according to what the application needs.
• Access policies: AD FS is mainly used for user authentication, but it can also provide authorization according to specific conditions the user must meet. Access policies have been designed with this goal in mind and they can block or allow access to an application through controls over the user’s location, group membership, and other criteria.

Along with the evolution of Microsoft’s technologies, AAD is the service that gradually replaced all the AD FS features listed here, and there are still some gaps left to be filled. AAD provides a much more comprehensive set of security features that align with the zero-trust approach to identity protection (and security in general) and that are a good fit for the modern enterprise landscape.

Customer Identity from SAP Customer Data Cloud

Customer Identity is a CIAM solution from SAP Customer Data Cloud that enables organizations to engage with their customers and connect them with their web applications.

Customer Identity provides a comprehensive list of features that simplify the collection of user information and the overall management effort of maintaining an enterprise CIAM solution:

• Registration and login options: There is a large number of built-in registration and login options, which include social login (such as Facebook, Twitter, Google, LinkedIn, Amazon, and Microsoft) and federated login using the SAML or OpenID Connect protocols. It is also possible to configure passwordless phone and push authentication and, to increase the security posture, risk-based authentication.
• Screen-Sets: Screen-Sets are sets of screens that govern the user interaction with Customer Identity by defining a user-facing flow. Flows typically belong to the following types: login and registration, forgotten passwords, profile updates, re-authentication, lite registration, or account linking.
• UI customization: Customer Identity has several tools that come in handy when the UI has to be customized. The powerful UI Builder allows you to easily customize the UI of each screen defined in a Screen-Set, which, together with CSS and markup personalization, allows you to create conditional workflows and visualize each message in the user’s preferred language.
• Integration tools: Through the IdentitySync Extract, Transport, Load (ETL) service, Customer Identity offers an API-based way to transfer data in bulk between platforms.

Furthermore, Customer Identity provides pre-built integrations with many notable CMSs, CRMs, and other systems.

• Admin tools: Several out-of-the-box tools ease administrative tasks by providing reports, customer insights, and audit logs.

Customer Identity provides all the capabilities needed to build a strong trust-based relationship with an organization’s customers.

Okta (Auth0)

Unlike Microsoft, Google, and Amazon, Okta is a company that we can call IAM-born. The core business of Okta is identity management; 100% of their business relates to identity management and, as a consequence, all the effort of the company is focused in this direction. In March 2021, Auth0 was acquired by Okta, another company that is focused on identity and the ecosystem around it.

Okta built its customer experience on top of the following pillars:

• Directories: The directory is the basic pillar of an enterprise that intends to adopt Okta. The directory is used to host resources, users, and groups. An Okta directory enables their customer to store an unlimited number of users, devices, and groups in a single and structured view. In the Okta language, a universal directory usually represents the main instance of the Okta IDP. Customers may use multiple directories if a company has multi-tenant ambitions.
• Integrations: This pillar encompasses the ability of the IDP for provisioning, de-provisioning, and federation with other IDPs. These integrations can represent the enablement of SSO capabilities thanks to protocols such as OIDC and SAML, or more advanced scenarios, such as automated user provisioning and integrations with Okta’s API.
• Insights: This pillar is connected with the Auditing and reporting decision factor reported in Table 7.1. The insights pillar refers to the ability to gain insights from user activities, be alerted to suspicious logins, and analyze the user’s behavior for business purposes (this capability can enable a business decision-maker to understand how many times a user logs in to a specific application and collect data that could be relevant for the business to understand where to focus the development investments).
• Identity Engine: Okta’s Identity Engine is the pillar for creating tailored user journeys. With a context-driven user journey, enterprises can address a wide range of identity use cases with minimal custom code.
• Workflows: Similar to Identity Engine, this pillar is more focused on those who aren’t developers to enable organizations to customize user journeys without writing a single line of custom code. The philosophy is “Enable anyone to automate identity-based processes and drive innovative new user experiences with a low/no-code interface and extensible platform service” (https://www.okta.com/platform/workflows/).
• Devices: Okta enables advanced features to enforce device security and enable a passwordless scenario whereby users can log in without entering their password by authenticating themselves via a device. Okta also provides multi-factor authentication capabilities with its own authenticator.

As highlighted in the Gartner Magic Quadrant diagram in Figure 7.1, Okta plays a crucial role in the identity market. It is considered a leader with a greater ability to execute its technology than anybody else. That’s the reason why Okta must be seriously considered when it is time to choose the IDP to use in an enterprise. The recent acquisition of Auth0 outlines the healthy status of the company, and the future, at the time of writing, seems to be good and completely focused on identity, unlike many of its competitors.

This section just scratched the surface of Okta’s features and capabilities. If you need to evaluate it as an IDP, we recommend going even deeper and directly browsing okta.com, which can provide up-to-date and more detailed information.

Summary

In this chapter, we reviewed the criteria for how a company should evaluate the IDP that they will choose. We discovered that there are not only technical factors at play in this choice but also regulation policies for specific businesses playing an important role. We reviewed all the technical aspects that should affect the choice of which IDP to use.

We also had the opportunity to describe, from a very high-level point of view, some of the IDPs that have a good standing on the market.

In the next chapter, we are going to move a step further and a level deeper: we are going to describe in detail how one of the most important IDPs works, look at its features, discuss the advantages and disadvantages of adopting it, and see the benefits an enterprise can obtain by leveraging features that are built on top of the OAuth protocol when choosing this IDP. We are going to have a closer look at AAD.