Category Archives: AAD B2C

Developer toolkit for working with Azure AD B2C JWT-protected APIs

I’ve blogged in the past about Azure Active Directory B2C and how you can use it as a secure turnkey consumer identity platform for your business.

In this post I’m going to walk through how you can debug JWT-protected APIs where those JWTs are being issued by AAD B2C. Note that a lot of what I write here will probably be applicable in any scenario where you are working with JWTs as AAD B2C is standards compliant so any advice here can be applied elsewhere.

We aren’t going to get into the Identity Experience Framework (IEF) here because he’s a whole universe of detail beyond the basic policy engine we’ll cover here 🙂

Your toolikit

Here’s the tools to get started with debugging.

Required tools:

  • A test AAD B2C tenant – a very strong recommendation *not* to use your production one!
  • An API testing tool like Postman. The B2C team has published how you can use Postman to test protected APIs.
  • Your API source code in a debug environment. Must be configured in the test AAD B2C tenant you are using!
  • A test client application – I’ve been using a customised version of the WPF sample client app from the B2C team.

Optional, but recommended:

  • jwt.ms (there is also jwt.io if you prefer)
  • Mailinator or any number of alternatives.
  • Create a B2C Profile Edit Policy even if you never roll it out to customers. This policy can be invoked via the Azure Portal to allow you to initialise new profile attributes.

Use standard OAuth libraries in your clients

Microsoft has great first-party support for B2C with the Microsoft Authentication Library (MSAL) across multiple platforms, but as B2C is designed to be an OAuth2 compliant service so any library that supports the specification should work with B2C. Microsoft provides samples that show how libraries like AppAuth can be used.

Rolling out custom attributes

There is currently a limitation with B2C around rolling out new custom attributes. Until an attribute is referenced in at least once policy in your tenant the attribute isn’t available to applications that utilise Graph API. This is why I always create a profile edit policy even that I can add new custom attributes to and then invoke the policy via the Azure Portal to initialise the attribute.

Testing APIs

Create test users

This is where a service like Mailinator comes in handy – you can create multiple test users and easily access the email notifications sent by B2C to perform actions like initial account validation or password reset.

Note: free services like Mailinator may be good for simple testing, but you may have security or compliance requirements that mean it can’t be used. In that case consider moving to a paid tier or other services that provide secured mailboxes (a service like outlook.com).

Request Tokens – Test Client Application

Once you have one or more test users you can then use one of the following approaches to obtain test tokens to use when calling APIs.

If you aren’t using Postman to retrieve tokens to supply in API calls then you can use the test client application above (assuming you are developing on Windows – or at some future point when we get WPF ported to .Net Core :)) to request tokens for users in your test tenant.

B2C Test Tool

Once you have the tokens you can copy them out and use them in Postman to make requests against your API by setting Authorization in Postman to use Bearer Tokens and then copying the value from the test tool into the ‘Token’ field.

Postman using a Token

If you’ve having issues with tokens being accepted by your API then you can leverage jwt.ms to review the contents of the token and see why it might be being rejected. A sample is shown below.

jwt.ms sample

If you have access to the target API source code make sure to debug that at the same time to see if you can identify why the token is being rejected.

As a guide the common failure reasons will include: token expired (or not yet valid); scopes are incorrect (if used); incorrect issuer (misconfiguration of client or API where they are not from the same B2C tenant); invalid client or audience ID.

So there we are! I hope you found this post useful in debugging B2C APIs – I certainly wish that I’d had something to reference when I started developing with B2C! Now I do! 😉

Tagged , , ,

Azure AD B2C Custom Attributes: How to easily find their unique key value

When working with Azure Active Directory B2C you can create what are known as Custom Attributes which allow you to store data about users beyond the attributes (firstname, lastname, etc) that are available out-of-the-box.

When you want to work with these Custom Attributes in a solution you build you will need to know the unique key of the attribute in order to reference it.

What do I mean by this? Let’s take a quick look using an example.

Note that you will need to be a B2C Global Admin in order to perform some tasks covered in this post.

Creating Custom Attributes

These are created via the Azure Management Portal. In my sample I am going to add an attribute to hold a tier rating for a user (say, Gold, Silver and Bronze) called “TierRating”.

The video below shows how you can do this.

Find Attribute’s Unique Key Value

Now we have this Custom Attribute created we will want to use it in our solution. If you’re eagle-eyed you may find in the Portal that these Custom attributes appear be named ‘extension_AttributeName’ (i.e. ‘extension_TierRating’).

This won’t work in your solution though 🙂

When you create a Custom Attribute this is actually being done for you by a custom application called the “b2c-extensions-app” that is deployed to all B2C tenants at provisioning time.

Why am I telling you this? I am telling you this because it’s the key to determining the Custom Attribute’s unique key value 🙂

You will need the Application ID for the b2c-extensions-app, which you can find in the Portal as shown in the video below.

Using it in your code

Now we have this value (in our demo video the value is ‘bb10b272-0267-46f0-8b6f-4367e8b1b1e6’) we can start to interact with Custom Attributes in our code.

Firstly we need to drop the dashes so it becomes ‘bb10b272026746f08b6f4367e8b1b1e6’. We combine this with the “Name” value for the Attribute, along with a prefix of “extension_”.

So for our tier rating Custom Attribute the full key for it becomes ‘extension_bb10b272026746f08b6f4367e8b1b1e6_TierRating’.

A sample of how this key is used in our solution is shown below.

This pattern is used for every Custom Attribute you create in this Directory.

So there we have it – the easiest way you can determine the actual unique key for a Custom Attribute!

Happy days 😎

Tagged , ,

AAD B2C Talk – Innovation Days 2016 Wrap

I recently spoke at the Innovation Days 2016 event held in Sydney on Azure AD B2C.

The presentation for my talk is available here:

https://1drv.ms/p/s!AqBI2LiKM4LHwNJvTxrXNAblpTBCJA

and you can find the sample code for the web and API apps here:

https://github.com/sjwaight/innovationdays2016/

Creating Azure AD B2C Service Principals with PowerShell

I’ve been lucky enough over the last few months to be working on some cool consumer-facing solutions with one of my customers. A big part of the work we’ve been doing in building Minimum Viable Product (MVP) solutions to allow us to quickly test concepts in-market using stable, production ready technologies.

As these are consumer solutions, the Azure Active Directory (AAD) B2C service was an obvious choice for identity management, made even more so by AAD B2C’s ability to act as a source-of-truth for consumer identity and profile information across a portfolio of applications and services.

AAD B2C and Graph API

The AAD B2C schema is extensible which allows you to add custom attributes to an identity. Some of these extension attributes you may wish the user to manage themselves (i.e. mobile phone number), and some may be system-managed or remotely-sourced value associated with the identity (i.e. Salesforce ContactID) that a user may never see or edit.

When we have attributes that the user doesn’t necessarily manage themselves, or we wish to do some other processing that isn’t part of the AAD B2C Policy framework we need to use the Graph API to programmatically access AAD B2C identities.

The AAD B2C team has a good overview document on how use Graph API with AAD B2C, but I ran into an issue creating a Service Principal for my Graph API code because I used an Azure AD (Enterprise) identity to create and manage my B2C instance. As I suspect this will be how the majority of instances are created I thought I would document my solution here.

Background

I have a demo AAD B2C setup below and you can clearly see my Kloud identity (creator / admin of the tenant) is sourced from “Microsoft Azure AD (other directory)”.

Admin user from another directory

Note that with this user I am still able to manage identities contained in the B2C directory via the web UI, but where I run into issues is with PowerShell as we will see.

As you can see in the AAD B2C post referenced earlier, I need to use the Azure AD PowerShell module to setup a Service Principal. Firstly, let’s connect:

Connect-MsolService

At the prompt I enter my admin credentials (simon.waight@kloud.com.au) and am connected.

You can probably already spot the issue… there is no way to pass a TenantId to this command – the context is entirely based on the user’s User Principal Name (UPN).

When I run:

Get-MSolDomain

all I see is the verified domains attached to my home tenant:

Home tenant domains

.. and my B2C domain isn’t one… so… no luck 😦

I read on through the documentation and looked at the PowerShell Cmdlets and found what I thought would be my solution – the ability to specify a Tenant ID on the New-MsolServicePrincipal Cmdlet as shown:

New-MsolServicePrincipal -DisplayName "Demo AAD B2C Graph Client" `
                         -TenantId bc1ec9c8-xxxx-xxxx-xxxx-e10e3ee114a8 `
                         -Type Password -Value "notmypassword"

I promptly received an error message advising me that I was not authorised to make changes in the specified tenant 🙂

The Solution

It’s actually pretty straight-forward – create a local adminstrative account in the AAD B2C directory and use this to authenticate when using PowerShell.

Add user step 1


Add user step 2


AAD B2C with extra admin

Once you have done this make sure to log into the Azure Portal using this new user (localadmin@simondemob2c.onmicrosoft.com in my example) and reset their password. If you are using the new AAD PowerShell Module that supports modern authentication you can do this in-line at login time.

Note: in order for MFA to work for this user at the PowerShell command prompt you should install the preview AAD module that supports modern authentication.

If I now run

Get-MSolDomain

I see the B2C directory I expect:

B2C tenant domains

I am now able to create the Service Principal I need for my Graph API client too:

New-MsolServicePrincipal -DisplayName "Demo AAD B2C Graph Client" `
                         -Type Password -Value "notmypassword"

returns the expected result of creating a Service Principal I can use for my Graph client.

Happy Days!

:mrgreen:

Tagged , , , , ,