Azure AD B2C (Business to Consumer)
In this episode of the Azure AD and Identity Show, your host, Simon May, talks to Stuart Kwan of the Identity Division about how Azure AD B2C can help you manage consumer identity-based access (Facebook, Microsoft, Google and more) to your Azure AD, making it much easier to implement identity in all your apps.
More resources and next steps
- Learn: Enterprise mobility core skills
- Try: Enterprise Mobility Suite (EMS) free evaluation
- Connect: Join the Identity conversation on Twitter
- Gartner Magic Quadrant: Visionary in Identity as a Service
- Watch: Get the inside track from Microsoft experts
[00:01] Simon: Hello, and welcome to the Azure Active Directory and Identity Show. My name is Simon May and I'm going to be using the show to take you through some of the new features that are coming out inside of Azure Active Directory and our identity services and just help you to get a bit of an understanding around what we're doing in that space.
[00:16] It's very fast-moving and every one of these episodes is going to be coming out very, very quickly. Joining me today is Stuart Kwan from the Identity team. Welcome to the Channel 9 studio.
[00:26] Stuart: Thank you very much
[00:27] Simon: What are we talking about?
[00:29] Stuart: We're going to talk about some of the difficulties people have building applications that face consumers today and face customers.
[00:37] Actually, what I'd like you to do just for a moment, trust me here on this one, I want you to close your eyes and I want you to think about all the different places that you sign in on the web, on your mobile app, on your phone and on your PC and stuff like that that are personal things that you do, so they're not work-related.
[00:54] You know you sign in to get your email. You sign in to various social networks. You sign in to your bank. If you're a parent, maybe you sign in to the PTA at your school, your travel sites, blogs that you might visit, games that you use, just lots of different places, right?
[01:09] So, you could have lots of different places that you sign in. Now, do you know what the real underlying significance of that is?
[01:14] Simon: Well, I guess from my point of view, there's something that I'm going to do with my behavior, which probably is not a best practice thing to do, which is to sign in to all of those with, probably going to use the same password, which is probably not the best thing to do.
[01:26] But it's the only way when I've got so many accounts to remember that I can actually deal with that. I guess there's something from the point of view of people that are building the applications, so it's going to be kind of a lot of work, I guess.
[01:38] Stuart: Yeah, there's this tremendous problem that all kinds of developers face when they're building these applications and more and more people are coming online; businesses are offering some kind of application that faces their customers or their alumni or students or parents or what have you and all of them have to code sign in.
[01:57] Because almost always if you're building one of these applications and there's something that you want to do in the application that's valuable, you've got to sign in before you can do that. So, it's an integral part of the application and it's not often top-of-mind when you're building the app.
[02:12] Simon: Yeah, I guess you just kind of think I'm just going to grab some kind of authentication mechanism afterwards and that leads to some strangeness.
[02:19] I've seen people build kind of their own authentication database and that kind of thing, kind of a bit hookey over time.
[02:27] Stuart: It used to be that you could just, you know, tack on a database with names and passwords and that was good enough. But, as it turns out it's getting more and more challenging over time just to handle the sign-in part of your application.
[02:38] In fact, if you do have one of these things today where you've got a database of names and passwords and that's how people are signing in, you've become a target for attack on the web precisely for one of the things that you mentioned earlier.
[02:49] A lot of people, you know, for good or for bad, they use the same user name and the same password in a lot of different places that they go to and attackers know this and they're starting to breach these sites, not so that they can get at the information of your app necessarily. Maybe they aren't interested in getting into your app.
[03:06] All they want is your list of names and passwords because that lets them take that stuff and attack other places where they really wanted to go potentially. So, anybody who has one of these lists of names and passwords is a target and that's a problem.
[03:21] A lot of people are recognizing this is a problem for an application that I'm building, but I have to have this online presence; I have to have my customers or my alumni or those people all being able to sign in to my app and the attacks are getting more and more sophisticated. This is a terrible thing. Now, that's just one problem.
[03:36] There's a couple of other things that people who are building and maintaining these applications have to deal with. One is they might think at the beginning and often people do, they think oh, well, how hard could this be?
[03:46] But, as it turns out, there's quite a bit of code that you end up needing to write, because you're not just signing people in; you're also signing them up and probably you'd want to validate their email address, so you have this mail you have to send and they get the secret link in the mail and they come back to you. I mean, you have to code all that.
[04:00] You have to code it when they forget their user name; you have to code it when they forget their password and then because sign-up and sign-in is something that is integral to getting to doing that valuable thing in the application, it's a really important critical path thing and people are constantly trying to tune it so that it's less and less friction, right.
[04:19] You want people to be able to sign up really quickly; you want them to be able to sign in really quickly. So, there's new techniques that are showing up. On mobile devices, people sign in with their phone number for some apps. Or there are places you go now on the web where they'll say you're going to use your email as the sign-in and they mean it.
[04:35] You won't ever have a password there. You'll just use enter your email and they'll send you an email and that's how you're going to get signed in, so they can try to avoid storing passwords and stuff like that.
[04:44] So, it's a moving target; there's all these innovations going on and you end up spending a good portion of your resources just to write that code and it's not time spent on your app and that's just one problem.
[04:56] A lot of people will then go buy something off the shelf, which is probably a good idea, because off-the-shelf software has probably been built by experts. They have looked for various security problems that might come up as a part of this, because identity is integral with security.
[05:10] But, as it turns out, a lot of the people we talked to, this off-the-shelf stuff they buy is very expensive and they pay a lot in licensing fees; they pay a lot in professional services and then they still have to apply development resources to do the integration and then finally, there's this other one very interesting problem that many people have.
[05:27] You might have millions and millions of users and the traffic might be very, very seasonal. So, maybe a lot during the year there's a very low average of traffic, of users coming and signing in to your site.
[05:40] But, then you might have some sort of event, a promotion or, you know, your Super Bowl commercial or when your people are submitting their tax returns or they're going back to school and there are these big peaks all of a sudden that you have to handle and that means you have to provision for the peak, especially if it's an on-premises system.
[05:59] You've got a lot of this idle hardware during other parts of the year, but you have to have it for managing that peak. That's the most important time for you to service your customers. So, it can be really tricky, as it turns out, to build and run one of these systems. So, as it turns out, Microsoft is in a very unique position to help people with this.
[06:18] Simon: When we've kind of got some of those systems, there's, then those peaks and drops with quite some time.
[06:22] I'm guessing things like Xbox is going to actually have some pretty significant peaks around the holiday season, as people get new Xboxes and start signing in with new accounts and that kind of thing and we see literally billions of authentications for Azure Active Directory for Office 365, so that we must have solved a lot of this already.
[06:41] Stuart: As it turns out, yeah, we have some of the biggest applications on the web. You've mentioned some of them, Office 365, Xbox Live, Outlook.com, and we have to sign users in; we have to sign users out for those applications and we have to protect them.
[06:53] You can imagine there's a lot of people who would like to break in and get at our identity system. So, we've spent a great deal of resources, a great deal of time, a great deal of energy to build these sign-in systems and to make them safe for our users to use.
[07:08] What if we could take all of that capability that we've built and we could make it available for other people to use as well in their applications, and that's essentially what I'm here to talk about today.
[07:20] We're launching this preview of a capability that we call Azure Active Directory B2C and it takes Azure Active Directory that we've already billed as this global service for Office 365.
[07:32] It has hundreds of millions of users in it and does billions of authentications per day, and we've added the features that you would need to make it a consumer-facing system that any developer could use to sign users in to their application and there's a couple of interesting benefits to this.
[07:47] So, we've added features like you can sign users in with Facebook and Google and stuff like that, and you can actually sign users in to accounts that just belong to your application.
[07:57] We've built this capability and because of the global scale of what we've done, because we've already built this system out, we're able to drive costs down in ways that other people can't, right.
[08:07] Just because we're in seventeen regions and more than two dozen data centers and with all the hardware and software, we can amortize out over this enormous system that we've built, we're able to drive costs down into building and running the system.
[08:19] We're able to pass those savings along to people who might want to use this capability and we're going to also charge for it on a consumption basis, so that you only pay for as much as you use.
[08:30] If during most of the year, you have very low traffic, you'll pay us a very low fee and then during those peaks, you'll pay, you know, commensurately for the amount of resources you're using during those big bubbles.
[08:40] But, we're able to handle all of that traffic, because we've got this great, big elastic cloud system and we're able to take everyone's traffic and sort of smooth it out across the big system that we've built.
[08:52] But, probably most importantly, because we're protecting our users, because we're protecting Xbox users and Office 365 users, we have hired whole teams of domain experts.
[09:04] Who do nothing but watch the threat landscape, watch the incoming traffic to the system, look for patterns that indicate anomalies, look for patterns that indicate fraud, look for botnets and their ingress into the system and how they might be attacking the system. We do all of those things.
[09:21] We have dedicated teams that are constantly watching the system and constantly adapting it, because it's an arms race. The attackers are getting more sophisticated and then we have to get more sophisticated.
[09:31] But, we can afford to invest the resources to stay on top of that and people who then use Azure A B2C will get all of the benefit of that, without having to do anything, just basically keep using our system.
[09:44] You won't have to hire security experts to stay on top of it and even if you tried to, you probably couldn't have enough people to do it to keep your level of sophistication higher than the attackers.
[09:55] Simon: So, we can basically take Azure Active Directory and extend it out to your consumers, your end-users, your partners potentially, as well, and because we're doing that on top of Microsoft's cloud on top of Azure, you get all of the economy of scale benefits, the security benefits, all of our future investment benefit; actually, you just get to leverage it very, very quickly.
[10:17] Stuart: Yeah, as it turns out, it's a problem well suited to solving in the cloud. We'll store your users' passwords for you; we'll make sure they're properly encrypted and hashed; we'll make sure that the bad guys can't come and get at them and then you don't have to think about that, so it's a pretty compelling fact. What I'd like to do is show you an example.
[10:34] So, I have an application that I've built here, a fictional application; our hero is Proseware and I've adapted it to use Azure AD for both sign-in and sign-up. So, let's go ahead and we'll sign a user up, as I click the signup button. So, Proseware is okay with people signing in with their social IDs, Google and Facebook or Microsoft.
[11:02] But, they also want to have an option for users to get an account at the Proseware application. They call this a Proseware account. You probably think of this too when you go to sign up somewhere.
[11:14] It's like sometimes you're okay using your Google account to sign in somewhere, but other times, you want to have an account directly in that application.
[11:19] Simon: Yeah, virtually every application on the web that I'm going to use, I actually end up saying, I want an account just for this, because if one of my other accounts has some kind of issue or I'm kind of locked out of it, for some reason.
[11:32] Because I forgot my Facebook password or wherever, I actually still need to have access to that thing which has now become a business-critical application. So, I kind of personally vary my approach. Sometimes, I'm using social accounts. Sometimes I'm using an account that's just local to that application.
[11:47] Stuart: I have this theory that everyone has their own little algorithm in their head about when they're going to pick to use their Facebook account or when they're going to pick to use their Microsoft account...
[11:55] When they're going to pick to use their Google account, when they're going to create an account and what of their set of passwords they use, they're going to use there, because, you know, well, my bank is important, so it has a special password, but oh, the blog and the PTA and that, although they all have to share the same password.
[12:12] Or you can get your medical records online and stuff like that now. Maybe that's yet a different case. But, the Azure AD B2C is giving the capabilities, all those different options. In fact, let's go ahead and we'll sign up the user with a Proseware account so that they have one of these accounts that's local to the Proseware application.
[12:33] We call these local accounts. So, I've got some stuff I can do here to sign up. Let's say that I want to use my Microsoft email address as my sign-in name. They want me to verify that I actually have that email address.
[12:46] So I'm going to go ahead and it's going to send off a verification email, and now actually what we're going to need to do is I'm going to flip to my email. Okay, well, so here we go. I've got the code. The code came back. We can lift the screen back up now.
[12:59] Alright, so I got this code in my email and I click verify and okay, so my email address is verified.
[13:06] And then, I'm going to create a unique password for this site and they want to know what name I want to be known as when I'm in the application and if I have a membership number or what kind of offering I want to have at Proseware, great. So, these are all things like membership number, offering...
[13:22] Simon: So, these are all custom attributes that you're creating somewhat?
[13:25] Stuart: Exactly, and I'll show you how I did that in a minute. But, yeah, that's not stuff that's in Active Directory, right? You don't see that stuff. I go ahead and I click continue to get completely signed up and I'm back in the application. I'm both signed up and signed in, so that all happened in one step.
[13:40] It knows that I'm Stuart and actually, you know, what? Oh, I forgot to ask you something. When we were looking at that screen just a moment ago, that sign-up screen, were you looking at the Proseware application?
[13:50] Simon: I thought so.
[13:53] Stuart: No, you weren't looking at the Proseware application. You were actually looking at Azure AD B2C in that moment. That was all user interface that was customized by me when I built the application, but it's actually all being hosted at Azure AD and there's an important reason for that. I entered my password on that screen.
[14:08] Simon: We want to make sure that that password is entered in to a site, which is secure.
[14:11] Stuart: Yes. We don't want you, the application developer, ever to have to handle it or ever see it. It's not in your hands, so you don't have to worry about it. It's all being rendered by Azure AD.
[14:21] Now, if you rewind the tape, which some people may even be tempted to do at the moment, you'll notice that the URL on the screen when I was doing the sign-up was firstname.lastname@example.org and that's the URL of the end point of Azure Active Directory.
[14:33] In the future even, so we don't have this for the preview, but later, we'll make it so that can be your URL, as well. So, you'll be able to give us an SSL certificate and then it'll just say Proseware.com, log in to Proseware.com. So, for all intents and purposes, it will look like Proseware everywhere in the browser and everywhere in the URL.
[14:53] But, it won't be Proseware rendering it; it'll be us rendering it. But, there won't be any way for anyone to tell that Microsoft's part of the interaction and that's important to us. This is really Platform as a Service for you to reuse and we don't need to be anywhere in that interaction. You need to be able to control it all yourself.
[15:09] So, I'm back at the application, let's see what it did actually send me, though. All the -- my app does is dump out what's called the contents of a JSON web token. This is the information about the user that was sent back and if you look here, you can see oh, well, there's the email address that was verified.
[15:26] We can tell it was a local account and the display name Stuart and oh, here's the membership number and the offering type that was gathered up. So, even that information that was gathered up during sign-in is sent in the token to the application so the application can know this information and start doing things with me.
[15:44] Simon: Cool, okay. So, it kind of feels like you've got an OpenID/OAuth 2 workflow type of thing happening in the background there.
[15:51] Stuart: It's actually exactly OpenID Connect, which is a fantastic segue to come back into my presentation here. We have a principle that we follow in Azure AD and that is that we want all interactions with the system to be based on open standards.
[16:09] So, the way that you authenticate to B2C is either through OAuth 2.0 or OpenID Connect and I would go OpenID Connect 1.0. I'll talk a little bit more specifically about how you fashion the request for that in a moment.
[16:20] But, it's a standard request and you can use standard libraries and stuff like that to interact with the system and not only do we have the authentication end point, but you can also fully program the directory and create users and delete them, read them, and stuff like that through the Graph API and the Graph API is just an OData REST API.
[16:41] So, again, it's a standard and it's really simple then to make these REST calls to create users, delete users and in fact, the stuff I showed, that signup screen and all that, you don't have to use that if you don't want to.
[16:52] If you have some other mechanism that you use to create accounts, some automated mechanism or you want to have absolutely full control over that, then you can do that and you can just create the accounts in our system using the REST API. So, you can take and use as much as you want of the system.
[17:09] But, we do OAuth 2.0, OpenID Connect and to help developers build applications, we also offer a full range of open source libraries and all of our libraries are posted up on GitHub and they're under an MIT license. We are happy to accept contributions back, if people find problems or if they want to add features.
[17:28] We accept pull requests on these libraries and we have them for .NET, of course, but also platforms like Node.js, iOS and Android. The system works equally well for web apps and mobile apps and PC apps, because, of course, Azure AD for things like Office 365 supports web apps, mobile apps, PC apps. So, we have that full range.
[17:49] In fact, that Proseware application, just for fun, when I built it, I actually built it using Node.js on Linux Ubuntu Server running in Microsoft Azure. So, I can, you know, go as far away from what you would expect from us, but really what a lot of people do when they're building these applications.
[18:07] Simon: Yeah, very cool.
[18:10] Stuart: Alright, so, yeah, let's talk very briefly about the requests. So, this is a typical Open ID Connect request. So, you know, we didn't invent anything new here. If you're familiar with OpenID Connect and you look at the request, you'll see stuff that's very familiar. The client ID represents the application.
[18:28] The redirect URIs, where tokens are going to get sent back to, scope, and response, these are all standard mechanisms. But, the special secret sauce, if you will, of this is this thing we call policies.
[18:41] So, there's an extra parameter that I've attached to the P parameter and it's indicating that a particular policy should be applied when this request goes through. So, actually, let me actually show you how I set all of this up in B2C.
[18:58] Simon: Let's take a look. So, the first thing I noticed immediately, actually I'm used to seeing everything inside of Active Directory inside of the old portal. This is in the new portal.
[19:12] Stuart: This is in the new portal. It's the first Azure AD components that are going to be in the new portal. What we're looking at right here is the control panel, if you will, the blade, that represents how I manage my Azure Active Directory B2C tenant.
[19:25] So, to build all of this, the very first thing I did was I went and I got a B2C tenant, as opposed to a regular Azure AD tenant. The assumptions are different in the B2C tenant.
[19:35] For example, in a regular Azure AD tenant, it's assumed that users can see each other, right, because I want to find people in the address book and they're my colleagues in an organization. In a B2C tenant, we don't want people to see each other. We don't want individual people to be able to browse and find out who else is a customer here or such.
[19:51] So, we have special or different tenants, Azure AD B2C tenant, and here's where I would register my application in the tenant, where I would configure that I accept Facebook and Google. I have to set that up, because I need to make registrations at Facebook and Google to get that working.
[20:07] Here I extend the schema or manage the schema of the directory and you can see the membership number and the offering type, the attributes of the user.
[20:17] I added them here and I could add as many other ones as I want, so that I can put the things into the directory that are important to my application and then there's these policies that then drive the behavior of the system.
[20:29] As you can see, we have different kinds of policies - sign-up, sign-in, profile editing or password reset when someone needs to self-service password reset. The system handles that for you. You don't have to write code for it.
[20:41] But let's take a look at a policy, so you can understand how this works. Let's look at the signup policies and in fact, in the previous example, I said there was the standard signup policy, which was part of that request when we did the demo.
[20:53] When I went into the Proseware app and I clicked the sign-up button, it sent an OpenID Connect request with that signup parameter on it, which activated this policy that I've created and I could have as many of these policies as I want and I'll tell you in a moment why that's important. So, I created this policy. Let's take a look at what's inside it.
[21:13] So, here, we can see if someone comes through this policy, then they're signing up and they can pick from one of these identity providers and if I wanted, I could uncheck these. Maybe I don't want to support Google and Facebook.
[21:24] Maybe just for this particular application or for this particular route through an application, I only want to support, say, a local account signup or I only want to support a Facebook signup.
[21:35] Then I could set that here in this policy and then also here's where I configured the fact that I asked the user for their display name, their email, their membership number and their offering type on that signup screen.
[21:48] So, I configured that here and then also I configured the list of information that gets sent back to the application, so, those claims that we saw on the app when I was done, the display name, email address, membership number, offering type, identity provider, so I can tell was this a Facebook user, a Google user, or a local user.
[22:08] Then finally, there's one other attribute that I'm sending here, which is important for this application. It's the object ID. That's the unique identifier for the app, because someone can change their email address; they can change their name, but I don't want that to mean that they suddenly have a different identity in my app.
[22:24] So, this is the rename safe information by the user. So, I've picked all of those things, and finally, if I wanted to, I could also configure multifactor authentication here.
[22:34] So, maybe when the user signs up, I want them to prove that they have a particular phone number, so they'll enter their phone number; they'll get a phone call and we'll verify it and then we can use that later if we need them to do a multifactor sign-in.
[22:48] Simon: Which is obviously going to help if they are using the same password in multiple places. It's going to actually put an extra layer of security around that.
[22:55] Stuart: An extra layer of security that you as the developer didn't need to write any code for, right. It's just we took care of that for you and if other new mechanisms show up, we'll add those mechanisms here and you won't have to write any code to take care of it.
[23:06] You just send us the OpenID Connect request. We apply the policy. We make sure the right things happen. We send the information back to you. Then finally, the last thing I did was I customized that signup page. So, here, how did I do that customization?
[23:22] Well, the policy allows me to set what the labels are going to be on the various fields, the input fields that have been set up, what kind of input fields. That offering type was a dropdown selection field, so I picked that here.
[23:37] Then finally, I supplied the HTML and the CSS that was used to render that page and that's why it looked like Proseware instead of looking like Azure AD. So, I can do all of that customization and make it look like my own site.
[23:50] Simon: Very cool. So, it seems like we've got a vast amount of flexibility in there, all the kind of things that you actually need to be able to use in order to get up and running. How do folks get hold of Azure B2C?
[24:02] Stuart: Well, so we're in preview. In fact, we've been in private preview for a little bit and we actually have some people who are using the private preview already. Let me just talk really briefly about Real Madrid. So, back in May at our Ignite conference, we announced that we had a big partnership with Real Madrid.
[24:19] We helped them build some new fan applications, mobile fan applications and Real Madrid's one of the most popular...
[24:28] Simon: ...soccer teams in the world, yeah.
[24:29] Stuart: ...yeah, sports clubs in the world, really, and they have 450 million fans and they were worried about okay, well, when we have this new fan app, we need people to sign in so we can have a personalized, you know, presentation for them of the application.
[24:42] Well, how are we going to have a sign-in that could possibly handle hundreds of millions of users? They partnered with us and we actually built their application on Azure A B2C while it was in private preview and there was actually a very brief moment where it was the number one application in the iTunes store.
[24:58] It was, like, ahead of Facebook and Instagram. It was the Real Madrid app and we handled lots of people signing in on those first few days when the application came out and we have a great partnership with them. We're very happy with how that worked out.
[25:13] Now, today, we are in public preview and if you go to the old Azure portal, you can create a B2C tenant. That's where you'll start, in the old Azure portal.
[25:24] So, you'll, in the Azure Active Directory section create a new tenant and there's a tick box there that says this is a B2C tenant and you say yes and then you'll be taken into the new portal and you'll be able to do that configuration that I just described.
[25:37] Once you've done that configuration, you can write your app, use our libraries, send those requests, requesting a policy. That's all it takes really. It's very straightforward.
[25:45] Simon: Very cool. It's like instantly preview; we can handle the scale, which was the first thing that we were talking about there. You can get hold of the features directly through the portals, nice and easy to get access to them. If you've got an MSDN subscription, easy way of trying it. If not, you can get a free Azure trial in order to try everything out.
[26:04] Stuart: In fact, yeah, so I have a list of features here just in summary. But, there's one thing people are probably wondering, is okay, well, it sounds really good, but how much is this going to cost?
[26:14] Simon: Yeah, that's a great point.
[26:15] Stuart: We think people are going to find this surprisingly affordable. The reason why we're able to make it so affordable, of course, is because Azure AD, we have an economy of scale that we can use to drive down costs as we run the system.
[26:30] Then that lets us, again, pass that saving along to people that are using it and since we're going to do it in a consumption basis and you're only going to pay for what you use, we think that's, like, the optimal model for folks.
[26:42] There will be three meters on the consumption and they're all per month, so, the number of users that you have in your tenant, the number of regular authentications you do per month, and the number of multifactor authentications you do per month. Each of those will have a different cost.
[26:57] If you want to find out exactly what the graduated scale looks like, that's if you do between this many and a million, between a million and ten million, ten million and higher, we have different charges and they go down as you go higher.
[27:09] If you want to find out exactly what those charges are, it's available on the Azure pricing page today with the announcement of the preview, and one last thing, there's also a free tier. So, at the first fifty-thousand users, the first fifty-thousand regular authentications are free. So, if you have a small site, you might be free forever.
[27:28] Or if you're just doing development and kicking the tires, it won't cost you anything to try this out.
[27:33] Simon: Cool, awesome. Stuart, thank you very much for joining me in the studio. We'll see you next time on the Azure AD and Identity Show.