So far, we’ve looked at integrating our corporate users into an Azure AD tenant. However, for may web applications, there will be a need to authenticate customers as well.
Traditionally, this would be provided on a per-application basis using a simple username/password combination stored in a local database. However, given that you may expose multiple applications and you would want to leverage the security benefits we’ve so far discussed, it would make more sense to leverage the highly secure capabilities of Azure AD.
Of course, what we don’t want to do is create user accounts in our domain; they still need to be completely separate from your corporate users. A single authentication mechanism for apps you are responsible for certainly makes sense, both from a management perspective (only having one user database to manage) and from an ease-of-integration perspective—why build a security mechanism for every app?
There are three main ways we can provide this access, listed as follows:
- Multi-tenancy
- B2C
- Business to Business (B2B)
We will look at each option in turn.
Multi-tenancy
With multi-tenancy, your applications support external Azure AD tenants—that is, as well as allowing our application to authenticate your users, you can also authorize against an external (that is, not yours) Azure AD tenant.
The following diagram shows the differences between the two models:
Figure 3.15 – Azure multi-tenancy
This option is excellent for enterprise-class applications for organizations—that is, when you’ve built a SaaS platform that is offered to companies as opposed to individuals. For example, Office 365 is an enterprise application design for companies and is always tied to an AD tenant, and therefore is available to employees of that company. In comparison, Facebook is for individual users who will sign in using personal email accounts.
Because of this, users must have an existing Azure AD account, either by having their own Azure tenant or an Office 365 tenant.
Consumer applications – B2C
B2C is essentially designed for individual customer applications—for example, a storefront or social site. Users would generally link their existing email to your B2C tenant, and their app would be built to authenticate against your app. Whenever you are signing up for a website and are given the option toSign in with Facebook or Sign In with your Microsoft Account, this is B2C.
Azure provides the ability to easily integrate third-party identity providers (IDP) such as Facebook, Google, LinkedIn, Twitter, and more.
Integrating third-party providers is as simple as registering the client ID and secrets from your external IDP into an Azure B2C tenant.
Users then authenticate directly against the IDP and not your tenant. Your tenant simply confirms with the IDP that your sign-in is valid.
Note that Azure B2C tenants are separate from your regular AD tenant—in other words, to set it up, you must create a new tenant as a B2C tenant.