Today we continue to explore the Azure B2C feature set and spend time on sign-in policies. Up to this point we have been using PowerShell to emulate a native client application. Unfortunately B2C is still in public preview and Microsoft hasn’t implemented support for sign-in, edit profile, and password reset profiles for native apps. To work around this, we need to be a bit creative.
To continue testing out these features we’re going to use PowerShell to construct our URI. We’ll then start up Fiddler, enter the URI into Internet Explorer, and observe the behavior from there. Before we begin, ensure you’ve setup your application according to the instructions from my first B2C post.
We need to do a bit more setup now that we’re going to emulate a web application. Run through the following steps.
- Configure the application to support Web App / Web API
Navigate to the Azure Management Portal and log in. Change your directory instance to the B2C directory you created by right clicking the person icon in the top right hand corner. Search for the B2C blade and hit the settings button. Navigate to the applications blade, select your application, and ensure that the Web App / Web API option is set to yes. Register a redirect URI of https://powershell. Refer to the image below.
- Create a Sign-In Policy
Next up we’ll create a sign-in policy. From within the settings section of the B2C blade, select the Sign-In policy blade and hit the Add button. Configure the following settings:
- Name: B2C_1_Signin
- Identity Providers: LinkedIn, Local Account Signin
- Application Claims: Select all claims
- Multifactor authentication: Off
- Page UI Customization: Default
Save the policy.
Now that we’ve configured our application with a web app redirect URI and added our sign-in policy we can begin testing. Download the PowerShell script linked below. We will use this script to generate our authorization request.
Once you have downloaded the ZIP, pull out the PowerShell script and fill in the appropriate fields with your tenant’s information. Run the script and copy the resulting URI.
Open Fiddler and ensure it is set to capture HTTPS traffic. You can double-check by going to to the Tools drop down menu, selecting Fiddler Options, navigating to the HTTPS tab and ensuring that both the Capture HTTPS CONNECTs and Decrypt HTTPS traffic are checked. Check out the screenshot below.
Now that Fiddler is capturing, open up your browser of choice and place the URI you generated from the script into the address bar. You browser will be redirected to Microsoft where you will need to choose your identity provider. For this example we will be choosing LinkedIn. You will be prompted to authenticate and give the application permissions to access your LinkedIn information.
After you have authenticated to LinkedIn your browser will be redirected to Microsoft to pickup the identity token and authorization code, then redirected once again to the redirect URI we configured in our earlier steps. The redirect will timeout and fail, but we don’t need to be concerned about that. Stop Fiddler from capturing and let’s examine the results. You’ll want to select the last captured session as seen in the screenshot below.
If we examine the XML in the page we received back from Microsoft, we see we received back both an id token and a code. Let’s tackle the code first. The code you receive back can be exchanged for a bearer access token from Microsoft. Right now that access token has limited purpose in that it can only be used within your application. You can’t use that token to access other resources like the Graph endpoint for the B2C directory. MS plans on adding more functionality to that token in the future.
Back to the id token. Copy the id token line from Fiddler, remove the XML, and paste the remained into a JWT decoder. I’m partial to Calebb. The result is something similar to the screenshot below.
Here we see again our IdP is LinkedIn and we receive some information from our LinkedIn profile including the job title and email address. Notice how we also received the values for the claims we had the user setup during sign-up. We could then take these claims and use them to customize the user’s experience to our application. Also notice the user’s OID, which we could be used to query for information about the user in the B2C Azure AD instance.
As you have seen through this example, the possibilities with B2C are many while the code to interact with it is simple enough for a non-developer to grasp and interact with. B2C represents an excellent way to demonstrate the power of modern identity standards and protocols like OAuth 2.0 and Open ID Connect 1.0 to your developer community.
In the next post we’ll play with both the edit profile and password reset portal. See you then!