Azure B2C : Integrating with Azure "Easy Auth"

I've done a series of posts around integrating applications with Azure AD B2C.

The theme to all of them is that B2C extends OAuth by adding the profiles to the request.

There's an example of this in the sample.

Another solution is to bridge "normal" OAuth and this extension with something like IdentityServer as described here.

And then I came across this article - App Service Auth and Azure AD B2C.

If your application is a web application in Azure (i.e. an app service), you can now integrate with B2C as per the article by using "easy auth".

What this means is that you can add the extended support via a few mouse clicks.

The end result is that your application can now connect directly to B2C without a bridge.

Powerful stuff!

There are a few gotchas as mentioned in the article.

You do not need an Azure subscription to create a B2C directory. However, you do need one to create an app. service that is required to get this to work.

So create another subscription and then map this to the B2C directory.

You can do this in the old Azure portal:

Another gotcha is that when you login to the new Azure portal, you may be in the wrong directory and get all sorts of access denied / rights issues.

You can make sure that you are in the B2C directory by clicking on your login name (top right) and then selecting the B2C directory in the "Directory" section in the drop down.

The third gotcha is to note this sentence "Note that in step 2, you’ll need to use the https address of the web app". If you just use the http address, you get a "URL must be in same domain" error.

Once authenticated, a quick way to see what claims you have is to to look in the trace.

Looking at the token in jwt.io, I see:

Now if you go to the web application and add "/.auth/me" to the URL i.e. something like:

https://xxx.azurewebsites.net/.auth/me

you get the JSON token:

etc.

Footnote:

If you take all the social logins that are possible, you start off in IdentityServer with:

Facebook, Google and Twitter

Working up the chain, Easy auth adds:

MSA, Facebook, Google, and Twitter

B2C adds:

MSA, Facebook, Google, LinkedIn, and Amazon

which could all end up in complete confusion :-)

Enjoy!

ADFS : All good things come to an end

One upon a time way back in 2008, Microsoft came up with a new direction for authentication and authorisation called "Claims-based authentication".

They had a new STS (that became ADFS) that had the codename "Geneva" and a new set of client-side classes to handle the WS-Fed interaction with Geneva called WIF.

It was announced in a blog post on November 3rd 2008.

And Vittorio Bertocci came on board as an evangelist to help spread the word.

To handle all the inevitable teething problems they created a forum. This was mainly focused on development.

The world rolls on, claims are now mainstream and underpin the Microsoft stack e.g. Office 365, Azure AD, SharePoint, CRM Dynamics etc.

WIF rolled through to OWIN (Katana) and OWIN is rolling through to IdentityServer in .NET Core.

ADFS 2.0 will shortly become ADFS 4.0 with far more functionality.

The ADFS proxy became WAP.

Vittorio is now a Principal PM with the Azure AD team.

And so this forum has closed.

Which is sad in a way. Looking back through my history, I first started answering questions in June 2011 - five long years ago.

Since then, I've contributed to almost 700 questions and hopefully helped a lot of people trying to get to grips with these products.

The content is still fully searchable so all that goodness lives on.

The good news is the forum lives on in a more focused way.

Hope to see you there!

Enjoy!

Azure B2C : FAQ

There is a lot of confusion around Azure Active Directory (AD) B2C as to where it sits so I thought I would do a FAQ around the questions I've been asked.

I will update this as new questions come in or feel free ask away in the comments.

Overview here.

Official Azure AD B2C FAQ here.

Q: How do I add a SaaS application to B2C?

A: B2C only supports Open ID Connect. It needs some OAuth tweaks to add in profile details. If the SaaS application can make those changes, then yes. If not, you need a bridge (see link). To support WS-Fed and SAML 2.0 you need a bridge as described here. (But note "easy auth" link below).

Q: I see that you used IdentityServer as a bridge. Is that the only solution?

A: No - you could use something like Auth0 as well. The key is that it has to be customisable and it has to be able to support both CP and RP.

Q: ADFS v4.0 (Server 2016) supports OIDC. Could I use this as a bridge?

A: No - ADFS v4.0 is not customisable and it only supports OIDC as a RP not as a CP.

Q: How can I do SSO with ADFS and B2C?

A: At the moment you can't. As above there is no way to connect them directly. However, you could try something like:

Application --> WS-Fed / SAML / OIDC --> ADFS --> WS-Fed / SAML --> IdentityServer --> OIDC --> B2C.

Q: Azure B2C runs on Azure AD. I can set up a federated tenant with ADFS and Azure AD. So why can't I do this with B2C?

A: B2C is a "different kind" of Azure AD tenant. It was developed for a use case of millions of external users that have no need for SaaS or federation.

Q: Can I use AAD Connect to provision my users in B2C?

A: No - that only works for "normal" Azure AD. In addition,  AAD Connect provisions users from AD. Typically, these are internal users inside a company's intranet. B2C supports a different use case - external users not directly employed by a company and on the internet. So it wouldn't make sense to use AAD Connect.

Q: So I can't programmatically provision my users in B2C?

A:  Yes you can via the Graph API. Have a look at the sample.

Q: Does B2C allow SSO across applications?

A: All applications that can authenticate with B2C have SSO across them.

Q: What about logout from B2C?

A: That's more a function of OIDC and currently there is no standardised logout functionality.

Q: Can I use the NuGet Microsoft OWIN OIDC package to connect to B2C?

A: No not OOTB - B2C uses profiles and these profiles have to be added to the OAuth message. Refer B2C sample code.

Q: So I can't use any standard OIDC library?

A: Not OOTB - they require customisation.

Q: My application is already hosted in Azure as an app. service. Can I integrate that?

A: Yes - refer to this "easy auth" link.

Q. What about other languages e.g Java?

A: I have heard of people using a Java OIDC library that they customised.

Q: I already have an Azure AD tenant. Can I use that for B2C?

A:  No - B2C is a "different kind" of Azure AD tenant. When you create a new Azure AD tenant, you'll see there is a check-box that asks you if this is for B2C. The Azure AD tenant is either "normal" or B2C - it can't be both.

Q: I have a number of different logons on B2C - local and some social. However, they are all for the same person i.e. me. Is there any way to link all these identities?

A: No - not at the moment.

Q: Can I add other social providers?

A: No - not at the moment.

Enjoy!

Azure B2C : Integration with IdentityServer

This post covered an overview of Azure Active Directory (AD) B2C and described some of the gotchas.

Imagine you have purchased a SaaS application that supports "normal" OpenID Connect. The vendor has quoted a ridiculous price to add the profile support necessary for the SaaS application to connect to Azure B2C.

One way around this (as you guessed from the title!)  is to add IdentityServer into the mix.

The path would then be:

SaaS application --> normal OIDC --> IdentityServer --> add profile info. to OIDC --> Azure B2C

The Azure AD B2C sample is Azure AD B2C preview: Build a .NET web app.

We need to add Azure B2C to IdentityServer as an external OIDC CP.

The SaaS application is added to IdentityServer as an OIDC RP.

For simplicity, just sign-in is covered. I'm assuming the user has already registered themselves.

As usual, here is the gist.

(Note that this is still a work in progress. Some B2C claims are not being passed through. I'm still investigating that. Hopefully, this does provide some guidance).

To test this out, I used this sample as the SaaS application. This uses "normal OIDC" to talk to IdentityServer.

The B2C sign-in profile is configured to allow local account login plus Facebook.

When the user clicks Sign-In in the application. they see this IdentityServer HRD screen.

The user selects "Azure B2C".

They then get redirected to B2C and:

They select "Local Account SignIn" and enter their credentials.

They are then redirected back to the application and see their claims.

To expand this into "SignUp", "Edit Details", "Reset Password" etc. you could have some more buttons on the HRD screen each tied into a different B2C profile.

However, this assumes that all applications will have the same set of authentication providers. For the case where some applications use Facebook only, some use local and Twitter etc. there will have to be some kind of mapping table mapping applications to providers.

And some of you will be asking "What about SaaS applications that use WS-Fed or SAML?". Good question, that was another reason to add IdentityServer into the mix and that is the subject of another post.

Enjoy!

OpenID Connect: Displaying the JWT

Just a quick post as I have had a number of questions around this recently.

If you are tracing an OpenID Connect connection e.g. to ADFS v4.0 or Azure AD, it is often useful to see what is in the JWT.

I use SAML tracer on Firefox. You can use this to trace anything not just SAML!

After authentication, look at the trace.

Here is the HTTP POST to my test application. Note the two tabs.

Now selecting the Parameter tab shows the id_token.

Copy and paste the Base64 string into https:jwt.io .

Paste into this box and you will see the decoded token.

Enjoy!

Azure B2C : An overview

This is a lead-in to future posts!

Azure Active Directory (AD) B2C (Business to Consumer) covers the use case where a company has internal users that use Office 365, Azure AD, some SaaS packages etc.

At the same time, they want to interact with external users but they don't want the details in the "internal" repository and they don't want hundreds of phone calls to the help desk about expired passwords etc.

They want the users to self-register and they want to be able to mine the user's details.

This is what B2C provides - a repository for external users only with self-registration and self-service password reset.

So you could imagine a company portal that allows users to browse the company products, read information about new products, register an interest in some future product etc.

This portal is then configured in B2C as an application (in the same way that you configure applications in Azure AD).

When the external user navigates to the application, they can choose to:

• Sign-up
• Sign-in
• Update details
• Reset their password

When the user signs-up, they are asked for a set of configurable details e.g. first name, last name, email etc. These details are then written to an Azure AD B2C repository.

When the user signs-in, they are redirected to B2C for authentication. They can log into the B2C repository or they can use some social logins. These all use OpenID Connect and then a JWT token is returned with the user's claims.

Sign-up, sign-in etc. all use policies. These are all configured in the Azure AD portal. You can have any number of these policies. An application specifies the policies it wants to use.

An example of a sign-up policy is to capture:

• First name
• Last name
• Email
• Address
• Postal code 
• Phone number

There are a number of built-in attributes (like email). You can also configure custom attributes.

Note that the email address is not of the form joe.bloggs@onmicrosoft.com. It can be e.g. joe.bloggs@gmail.com.

An example of a sign-in policy is to allow:

• Local
• Facebook
• LinkedIn

B2C can scale to millions of users.

B2C also supports the Graph API so user CRUD etc. can be done programmatically.

More B2C information.

The downside is that:

• These users cannot interact with any SaaS offering e.g. they cannot have Office 365 licences
• They are in a separate Azure AD repository so they can't interact with users in a "normal" repository
• Only OpenID Connect is supported
• The policies need to be sent in the OAuth messages so this is not "normal" OAuth

Ways around these problems will be addressed on the next few posts.

Enjoy!