The impact of identities on the UX

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.