Rory Braybrook
Jul 4 · 4 min read

I’ve been looking at this, mainly from the perspective of the new “App registrations” flow.

When you create an application, you are asked:

Essentially, just the name and the account type is needed. You can leave the redirect URI blank — more later.

If you are not sure of the types, click “Help me choose”.

It then takes you to the overview page and you’ll also see:

If you click on e.g. the .NET one, you see:

Clicking this adds the redirect URI for you! So much easier then trying to figure out what it is, whether there is a trailing slash at the end etc.

After clicking this, you see:

So it tells you what is going to happen. If you click the button, you see:

Then:

Because you do this from inside the portal, Azure AD knows the ID of this client and tenant so the values are pre-populated for you.

All you have to do is copy / paste this into the web.config.

So lets recap.

I have to:

  • Think of a name for my app registration
  • Specify an account type
  • Click two buttons for the redirect URI
  • Download the GitHub sample
  • Copy / paste the ID’s into the web.config
  • Build
  • Run

and I have a working sample in less than five minutes!

Running the sample shows:

Click the button and I see the Azure AD login screen:

(The background BTW is Long Bay in Auckland).

and it shows me all my claims:

I created this sample plus a WPF one plus a .NET Core one and had it all working inside ten minutes.

They can all use the same app registration which is a bonus compared to the old way where I had to have a different registration for each sample. Plus it was all manual and I had to decide between web app / API and native.

Five minutes after I started, I had a fully-working Identity solution with Azure AD and I can now get on with adding the business logic without having to figure out all the Identity details.

The plumbing is hidden from me. I didn’t need to know that the solution uses OWIN middleware or that the protocol is OpenID Connect or that it uses the Microsoft Authentication Library (MSAL) or that the endpoint is a V2 one.

And I can get all the other Azure goodness as well e.g. password protection, conditional access, MFA etc. if required.

You can see that we are heading towards friction-less or seamless Identity.

This is very much a trend in the industry and you can see other vendors like Auth0 and Okta all heading in the same direction.

It is so much easier than it was, especially from a developer perspective.

All good!

The new control plane

“Identity is the new control plane”. Articles around Microsoft Identity, Auth0 and identityserver. Click the “Archive” link at the bottom for more posts.

Rory Braybrook

Written by

NZ Microsoft Identity dude. Microsoft MVP. Azure AD/B2C/ADFS. Plus Auth0/identityserver. N. Shore .NET UG Admin. Presentations: http://bit.ly/334ZPt5

The new control plane

“Identity is the new control plane”. Articles around Microsoft Identity, Auth0 and identityserver. Click the “Archive” link at the bottom for more posts.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade