Managing user identities is something you’re highly likely to experience if you are working with (or in) a big customer-centered organization. I’ve prepared for you a case study in dealing with problematic user identities. Here’s how we built a first-class loyalty app for a huge retail chain using Azure AD B2C.
Imagine for a moment that you are leading the IT department for a retail chain organization. You are sitting in a meeting; the sales and marketing heads are with you. Suggestions are flying all over the place.
And then someone has an idea – let’s build an online loyalty app for our customers.
Competitors did it! We should too.
Now, Marketing & Sales, of course, think this is a piece of cake.
You – as an IT professional, on the other hand, see the real complexity behind this task…
This was a case I was working on with a company running a retail chain. What’s cool nowadays is that you don’t need to build much from scratch.
You just need to pick the right services and design how they cooperate with each other.
Let’s see how we did it.
There are multiple services available in IdaaS space. There is growing demand for it, and the market is responding with products.
In our case, we have chosen Azure Active Directory B2C (AAD B2C) as the solution.
It is a consumer-focused IdaaS offered by Microsoft.
If you are familiar with Azure AD, you’ll notice that Azure Active Directory B2C is built on the same underlying technology for scale and security, but its focus is on CONSUMER IDENTITY.
Here are some essential details you need to know about this service:
Already using Azure AD and puzzled with differences between versions? We have it covered for you in another article on the blog. Check it out here.
Let’s look into the process of how we set it up.
Every journey starts somewhere – in our case, the first step was to build the right application architecture. It had to support the current application need and provide an identity handling service for all new applications going forward.
Our choice was to use Azure AD B2C as a service and trusted identity provider.
Azure AD B2C is provided as a service. You don’t have to deploy it on your own, just start a service tenant, and you are ready to go.
The Web and mobile applications can integrate with it, using a simple API model and a set of libraries.
It is based on OpenID Connect and OAuth (but it can handle more protocols like SAML). Developers will not have a problem with getting the right samples and SDK’s for specific platforms. In this link, you will find a guide on how to start with your own application and AAD B2C.
A user coming to the web application is redirected to Azure AD B2C for authentication – via social media identity or local identity. In more advanced scenarios we can also use external identity providers. Using this capability, we can allow your employees to access these apps using their corporate accounts.
Permitted authentication methods and the user journey in the process are controlled through policies – you can build multiple rules here for what is permitted in which application.
In this video, you can see how solution components interact with each other from an architectural point of view.
Identity service takes care of the user registration process, if they come here for the first time – it gathers required consents and profile information.
Wait – what if we have the users’ data already?
It’s highly likely that you’ve collected your user information in the past as part of some campaign or from one of the many applications built previously.
Will they have to register again?
The good news is that we can handle this! Azure AD B2C delivers a processing engine for the identity pipeline – Identity Experience Engine.
Azure AD B2C is using policies configured within the service to let you control the user journey through the sign-up and sign-in process.
You are in control of other elements like profile editing and password reset policies as well.
The first policy element you will discover with this service is the configuration of identity providers. You can assign different providers (like Google, Facebook, Amazon, Microsoft – the list continues) for different policies.
Effectively, this controls how users get authenticated and how their data are processed before it reaches the application.
In this video, I show you how you can configure and enable applications with a new identity provider through policies configuration.
These are basic operations. But it might get more complex in real use cases. This is where advanced policies step in.
Using Azure AD B2C policies you can pull user information from your existing consumer data system. You can match it, process it and issue information for the application.
You can do some advanced things as well. Going back to our example of existing user data – your policies can be configured to do just-in-time data migration from an existing data source to Azure AD B2C in the instant a user first signs-in to your application.
Do you need to step up the authentication process when a user wants to perform some sensitive information? No problem!
Add an additional 2-factor authentication before the user can do this through policy configuration.
Right, so we now have the user signed-in and authenticated in our application. What’s next?
The application needs to call an API to execute actions!
Azure AD B2C is built to support the OAuth 2.0 authorization framework. Once a user is authenticated in the application, the app can call the API to obtain data and perform business functions.
You can’t allow anyone to call your APIs. It wouldn’t be wise on the Internet. We need proper authorization.
To provide it, the application can requests an access token to a specific API from the service.
The API is registered with the service as well and can receive and validate tokens issued from Azure AD B2C.
At the service level, we can control which application can call which API and what OAuth scopes this application can use.
On the screenshot below you can see a new addition to Azure AD B2C functionality – ability to control APIs scopes (in OAuth 2.0 terms) which can be called by an application.
Access tokens issued for this application will contain only the scopes granted for a given API at the service level. This is another access control layer in the service.
This is a common need: To store and provide some specific information about a user profile.
How can we collect it?
Again service policies come into play. When a user signs-up to the service, we can guide the user through a journey to capture additional pieces of data, mobile phone, consent to send newsletters and so on. Don’t worry, users are still allowed to change this through their profile settings.
All this information is stored in a service directory.
How can the application access it?
It can pull it from the service using a Graph API – REST interface exposing access to directory data stored in Azure AD B2C.
Using a Graph API is easy and intuitive for developers. If you want to try it there are plenty of examples on how to do this. Here you have examples and code snippets provided by Microsoft on how an app can interact with Azure AD B2C data through a Graph API.
Don’t worry. It’s not like everyone can query this information. Access to the Graph API is secured with the same security model. So it’s locked down tight.
This example is about a retail company.
But of course, it can be used in many other cases.
The list goes on.
Azure AD B2C is also used by government organizations at a national or local state level to enable its citizens to access digital services.
If you are in the local government area, this might be the missing piece to start a digital revolution.
Why not build this service on your own? Your development team can probably pull off some solution or find examples on the web on how to do this with your own code.
True. But, in the end, it’s all about customer data and security – in this day and age, this can’t be taken lightly.
To address this issue, we have used a cloud service where its main goal is to protect your customer identity. AAD B2C built on top of the Azure platform uses its scale and security to protect your consumer identity information.
In this video I discuss the security features of Azure AD B2C (from 12:26):
Azure AD B2c – Security Features
Here are the key benefits from the IT perspective:
And here are some key benefits from a business perspective:
Business scenarios in consumer identity are a broad topic and we can’t explore it all in a single blog post.
I’ve presented the basics of the service – its use cases, benefits and the general architecture of the service and applications based on it. But it is not limited to these elements. There is room for it to be much more advanced and address multiple scenarios.
You can use the same pattern in your industry, regardless if it’s retail, sales, manufacturing or delivering utility services. The same service can be applied in different ways to address specific requirements or user application flow.
We will be covering case studies of our projects and solution patterns of what we’ve learned on practical projects delivered to our clients. If you want to explore the Azure AD B2C service further, I encourage you to read the following articles by our expert Daniel Krzyczkowski:
Along with improved DevOps expertise comes a better performance of delivery teams. And when many deployments take place ...
It is a very exciting moment for each team member when the project they are to work on has a well-defined scope and is w...