Almost every interaction of consequence in our lives requires us to authenticate ourselves. In most countries around the world the process of acquiring our very first credential which attests to who we are happens at birth. From there we build a chain of other credentials which as we grow up and participate in society which allow others to know within some degree of certainty that you are who you say you are - and that you are allowed to perform a certain activity.

Today we bridge our real world credentials into electronic credentials so that we can interact with others that are on the other side of the world. Your credit card number, combined with its expiry date and CCV (or equivalent) number are just one way of authenticating that you have the right to perform a transaction online. Virtually everything we do online beyond to most basic web-browsing activity requires us to authenticate ourselves and as such building user identity solutions into applications is a common software development activity.

When it comes to building an identity platform for your application its important to correctly categorise the kind of problem that you are trying to solve. Whilst almost every application requires some kind of mechanism to authenticate users, the kind of relationship that application has with the user can often be quite different, and this changes the approach that you might want to take.

Business to Consumer

Business to Consumer (or B2C) is an incredibly common kind of identity management problem. This is the problem that a retail site is solving when they ask you to create an account upon check-out for that new pair of shoes you are buying. They do this so that they can streamline subsequent interactions with you, such as checking order status, amending and cancelling orders and initiating warranties and returns.

Conceptually, B2C identity is very simple - right up until you start needing to protect multiple resources (sites) and interact with social media platforms. For example, many users today expect to be able to authenticate to your site using their Facebook account (for example).

It is also common for retailers to have multiple brands either as a product of acquisition or to cater to multiple customer segments. In this context they will often want to have a single user identity which works across all of their online properties. At this point your identity platform is getting quite complex as you cater for cross site authentication flows. The opportunity to open yourself up to serious security risks also increases.

Business to Employee

Another common kind of identity management problem is Business to Employee (B2E). In the B2E scenario an organisation issues credentials to their staff which are then used to access internal systems, or increasingly externally hosted systems that are offered as a Software-as-a-Service (SaaS) solution.

The rapid adoption of cloud-based SaaS solutions has created numerous challenges around identity management. The first that an application developer will experience is the fact that the resource (their application) is no longer inside the same security boundary as their user, this means that operating system-level security protocols generally won't work. There are good ways of working around this, along with a bunch of bad ones with varying qualities of user experience.

One of the goals with B2E identity is to reduce the number of individual credentials that users are tracking either by making sure that usernames and passwords are (securely) synchronised, and ideally reducing the need to login multiple times.

Business to Business

Business to Business (or B2B) is perhaps one of the most interesting identity problems. Often in a B2B scenario one business has a resource (such as an application) that they want to share with nominated employees of another business. Rather than creating an account in their user directory and managing those users account, they want to invite the partner business to have their users, using their existing credentials to access the application.

There are several benefits to this approach. First, the business who's employees are being invited to user the application shoulder the burden of managing those users (although not necessarily their access levels). Second, the partner business is best positioned to understand the lifecycle of those users. For example if a staff member is terminated, they would disable their account and that would flow through to all the applications that user was using. In a case where a separate credential was issued, the partner organisation would be helpless to stop that user accessing their customers systems.

Selecting an Identity Platform

If I'm building an application, one of the things that I don't want to do is build my own identity platform from scratch. To be clear, each application generally needs to have its own authorization framework which maps the functionality being exposed, but identity should really be an external responsibility.

The question then becomes, what identity platform do you select? To answer that you really need to understand what kind of identity problem you have (see above). Once you understand that you can zero in on the solution that makes sense for you.

For example, in a B2E scenario you'll almost always shave some existing kind of user identity store internally. So your identity platform needs to be able to integrate directly with that and then allow your applications to leverage that existing integration to authenticate users. For organisations using Active Directory the most obvious choice is Azure Active Directory. Azure Active Directory can synchronize your users and groups to the cloud so that other (registered and approved) applications can authenticate users. Because AAD is becoming so ubiquitous many SaaS vendors are starting to integrate it out of the box which leads to much lower implementation friction around B2E identity.

AAD also enables B2B identity scenarios by allowing an AAD administrator to invite users from another organisation that is also using AAD to use a specific application. This addresses one of the primary considerations around Business to Business identity which is who controls the user account. In this case the home directory of the user stores the users identity details (username/password etc) but the directory protecting the application resource can constrain what rights that particular user has via groups. Initially this kind of identity topology was difficult to setup but recent improvements in AAD have dramatically simplified the process for most purposes.

That leaves B2C identity. You could simply decide to defer this problem to one of the social media sites by forcing all of your users to authenticate via Facebook of Twitter (for example), or you could build your own identity stack which supports username/password and social media identity - all the while looking wistfully at how easy line of business application developers have it.

Fortunately Microsoft identified the gap in their AAD offering and built an extension on AAD which supports Business to Consumer scenarios. Adding B2C features to an AAD directory brings several affordances that are necessary for consumer scenarios. For example the ability for users to create their own accounts (registration), manage password resets when they've forgotten their password. User e-mail addresses from arbitrary domains and customize the various screens to match the branding of your own sites. In addition, AAD B2C provides the ability to link user accounts with social media identities should that be required.

For most common scenarios, AAD can probably handle what you need to do. Sometimes however you'll need to still do some work to implement identity within your applications. One scenario that is common enough to mention is where you are yourself building a SaaS application where you want to support both independent individuals and users who are members of organisations. There is a new model going for AAD that can handle this fortunately but it is still in preview and a few features are missing.

Future of Identity

Identity is a fascinating space right now as we see cloud and mobility converge of interesting social trends. One area that I think we'll see some friction is over who logically owns a users identity and some more sophistication around cloud-based identities. But what do I mean by this?

The truth is that the company you work for really doesn't need to control the credentials that you use to identify yourself as an individual. In fact, they don't need to control anything about your identity. All they really need to do is authorize whatever credential that you present to them to access specific resources. Where you are interacting with other users and other organisations you would interact with them as an agent of the company you work for and its that agency that your host organization has control over. I believe that in the coming half decade we are going to need to solve the "Agent Identity" problem. I'm looking forward to what solutions we as an industry collectively come up with in this space.