Using a QR code with Azure AD B2C

There’s a custom policy sample for TOTP here.

There’s some documentation around MFA and TOTP display controls

The sample assumes that you are only going to proof up with one authentication application.

To that end, it calls “AzureMfa-GetAvailableDevices” and in the user journey, it checks “numberOfAvailableDevices” and if zero, then run proof up, otherwise run verify.

It also searches for some attribute to use as a signin name.

In my sample, I assume that the user has a username.

The issue is when the user has more than one application e.g. Microsoft and Google Authenticator. The original sample only allows one.

My sample asks the user if they want to proof up or verify, allowing the user to add multiple devices.

As usual, the gist is here.

Create a user in B2C with a username. I used “joeqr”.

Image of text box with “joeqr”

“Sign in” with “joeqr”.

Image with “Proof Up” or “Verify” options

It then asks if you want to proof up or verify.

I select “Proof Up”

Image with QR code and “Can’t scan” and “Still having trouble” links

We then get the proof up page.

If you click “Can’t scan?”, you get:

otpauth://totp/AzureQR:joeqr?secret=alvgagagai57v5w2&issuer=My+issuer

Note: You see the same string if you hover over the QR code.

“AzureQR” is the issuer I specified:

<ClaimsTransformation Id=”CreateIssuer” TransformationMethod=”CreateStringClaim”>
<InputParameters>
<InputParameter Id=”value” DataType=”string” Value=”AzureQR”/>
</InputParameters>
<OutputClaims>
<OutputClaim ClaimTypeReferenceId=”issuer” TransformationClaimType=”createdClaim”/>
</OutputClaims>
</ClaimsTransformation>

“My issuer” is part of “CreateUriString”.

<InputParameter Id=”query.issuer” DataType=”string” Value=”My issuer”/>

“joeqr” is the username.

In the back end, B2C keeps a record of all the secret keys and the number of devices. The primary key into this is the user’s UPN. That’s why the policy calls:

“AAD-UserReadUsingUserName”

I need to get joeqr’s UPN.

If you click “Still having trouble?”, you see:

Image with “Account Name” and “Secret” so you can enter the details manually,

So you can enter the details manually.

Scan the QR code with your authenticator of choice.

First, I use the authenticator extension and scan the QR code. Then click “Continue”.

Image asking you to enter the OTP for verification.

Now I get the OTP code from the extension and enter it. I’m now proofed up.

I then run the policy and select “Verify”. Again I enter the OTP and I’m verified.

Now I repeat the process with Microsoft Authenticator.

At the end of the process, I see in the JWT:

“numberOfAvailableDevices”: “2”

Now I repeat the process with Google Authenticator.

At the end of the process, I see in the JWT:

“numberOfAvailableDevices”: “3”

The interesting thing is that the backend will accept any of the three possible OTP. Note that they are not the same. Each application generates a different OTP.

If you look at the user’s “Authentication methods” in the portal using the new experience, you see:

Image showing “Usable authentication methods:”with three authenticators.

If you click each entry, you can delete it.

You can also use the Graph API to delete an entry.

All good!

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Rory Braybrook

Rory Braybrook

NZ Microsoft Identity dude and MVP. Azure AD/B2C/ADFS/Auth0/identityserver. StackOverflow: https://bit.ly/2XU4yvJ Presentations: http://bit.ly/334ZPt5