>> Save the date, July 29th for .NET Conf, Focus on F#.
Join us for this free one day
live stream event that features speakers from
the community and Microsoft Teams
working on and using the F# language.
Learn how F# lets you write the synced, performant,
and robust code backed by the powerful type system
in .NET runtime you can trust to build mission critical software.
Hear from language designers and experts
using F# in a variety of ways.
From building minimal web APIs to performing data manipulation,
interactive programming, machine learning, and data science.
Tune in on July 29th,
ask questions live and learn more about what F# can do for you.
>> Join us for this episode of fun .NET.
I've got JP, my very good friend JP to talk to us about
migrating to modern authentication in .NET. See you soon.
[MUSIC]
>> What's up everyone? Welcome back to another On .NET Show.
Today, again, I have my very good friend JP,
to talk to us about migrating to modern authentication.
This is a very hot topic
because a lot of things are happening around the .NET space.
We have .NET 6 coming,
quite a few changes around
the identity space as well since last September.
We have JP here to tell us why,
how, and where to go next.
Hey JP, how you doing, my friend?
>> Hi Christos, how are you?
Fancy seeing you here. It's been a while.
>> Yeah. Long time,
no speak since yesterday afternoon.
>> Yeah, we're talking about app migration today.
It's a huge thing that people have to do.
It's a lot of work, takes a lot of effort
and because everybody's app is a little bit different.
Everybody's app is using identity in some way or another,
and migrate might mean one thing to
one person and something completely different to somebody else.
We're going to take a look at a few things that
we've got to make it a little bit easier.
>> Yes. We're talking about Microsoft Identity,
not just any identity.
Specifically, we're talking about Microsoft Identity.
Why is it so important right now to start looking about migrating?
>> Well, I think we've got
some timelines that are coming up that are changing.
Things like there's an old library called ADAL,
Active Directory Authentication Library.
That ADAL library is going to be deprecated next summer.
Summer of 2022, that library's going to be
deprecated and it's already not giving any new enhancements,
only security fixes right now.
Everything that we have,
has been migrated to the Microsoft Authentication Library,
which of course we call MSAL.
MSAL is available for lots of different languages.
JavaScript, .NET, Java,
Objective C, all different languages
and platforms which you need to build it in,
and it's got a ton of new features
that keep you up to date with where
the identity industry's going and best practices
for security and all that fun stuff.
>> More security updates.
It's going to be the current one so I'm solid
is going to be the defactor one.
It's been for the last few years anyway,
but people had been slow in migrating.
It adds some additional capabilities that
ADAL did not support out of the books before. How hard?
I know that every software is a little bit of a snowflake
and every piece of code that you write is special.
You're never going to have two identical things.
But I suspect that are some common patterns to
allow developers to migrate from the old code, to the new code.
>> Yes. We look at these,
especially something like older .NET apps.
If you're in the middle of an ASP.NET Framework
to .NET Core type of migration,
I guess it's not even called .NET Core anymore
.NET 5 will just be straight up .NET.
If you're in the middle one of those,
because you're going to be in the guts and you're going
to be making a bunch of code changes anyway,
it's actually a really good time to start
looking at what your alternatives might be.
We've got a few different things to take a look
at now when it comes to identity.
Of course there's ASP.NET Identity as it exists today,
and ASP.NET Identity offers a lot of base functionality.
If you're migrating from ASP.NET
Identity or if you want to upgrade that,
there are still lots of ways to use ASP.NET Identity
and Azure AD and Microsoft Identity together.
Things like ON and the like,
you can still use Azure AD as
an identity provider into ASP.NET Identity.
As you're migrating off of
that old membership database into something like Azure AD,
you can go ahead and start doing
that migration without blowing up all of your identity code.
>> Nice.
>> In fact, you and I did a show on
that almost a year ago today, right?
>> We did.
>> Yeah, migrating from one to the other.
>> There will be a blog post following this one
to summarize the links and everything else that
we're going to be covering today so
people can go and actually look at
that and get an idea of what they need to do in the coming months.
>> Yeah. If you're coming from ASP.NET Identity,
you've got a lot of work ahead of you for lack of better term.
If you're coming from ADAL, however,
the MSAL migration is a lot more straightforward.
A lot of the concepts that were in
ADAL were carried over into MSAL.
You can think of it like an ADAL plus plus.
It's got a lot of new features and a lot
of a modern design behind it.
But the API surface is still pretty similar.
If you're used to things like the authentication context
for getting tokens or for signing in users.
The authentication context is still there.
We just call them confidential client applications now.
There are some docs that we've got already.
We've got one doc that's all about migrating
from MSAL.NET to Microsoft.Identity.Web,
and that's something we haven't actually talked about yet.
If we look at the libraries that we have,
we've got ADAL and we've got MSAL now.
MSAL is purely a token acquisition library,
it's just for us to go to the identity service and get a token,
cache it and do some stuff with it.
But it's just for getting tokens.
Doesn't necessarily sign in the user
because we're going to typically in .NET world anyway,
we're going to defer to as things like
ASP.NET to actually do the mechanics of signing in the user.
>> Right.
>> Because ASP.NET is going to do things
like redirect the user to go sign in and
then validate their token and write a cookie for example.
ASP.NET itself is going to do that,
whereas we need a token to go
call our graph service or to call your own API.
That's what we traditionally use MSAL for.
Historically, that's a pain to have to wire
up. I don't want to be-
>> There were two different distinct systems,
ASP.NET will do the sign-in
and then you had MSAL to go and acquire your tokens.
I had to wire them separately and there were
not particularly nice in playing together.
>> That's right. It was not a super great experience.
In fact, I've got a little bit of code up here on the screen.
We'll take a look at this. We got a little bit of older code here,
and this uses the OpenID.
>> That's a lot of code.
>> I mean, look at things like global ASAX,
this is like archaeology right now.
>> Yeah.
>> But we've got things that were using
OpenID Connect, which is
the protocol that we use in Azure AD for sign-in,
we're using OpenID Connect and we're letting
ASP.NET handle, and in this case ASP.NET ON,
it's handling all the interaction with
the OpenID Connect upstream.
You'll notice we have things down here
like Authorization Code received,
this method here, and this delegate that we have to write.
Now we're taking what ASP.NET is
doing and then we're pulling in
MSAL and we're saying, "Hey, MSAL,
you should go and redeem this token,
redeem this authorization code so I
could get a token stuff into the cache and all that.
It's a lot of interactive work,
and it requires you as the developer to
have a lot of protocol knowledge,
I guess is the right way to describe it.
>> Yeah.
>> You need to understand what an authorization code is.
You need to understand when in
the pipeline you're going to get that authorization code,
how to handle it, and then caching the results of it.
Because when you get the authorization code,
you probably don't actually necessarily
need that token right then.
This whole blob of code,
which is a fairly considerable amount of code.
>> Ninety lines, as I can see, or more or less.
>> Yeah, it's a lot of code.
It starts at line 34 and goes to line 96, so it's a lot of code.
>> If we look at a more modern version of this, however,
we'll see that the code that we need to do the exact same thing,
which is to redeem authorization codes,
and put those into caches,
and do all of that work,
has been reduced to really one line of code,
but it's just on four lines to make it easier to read.
>> Snap, that is amazing.
>> Yeah. Our first line here are AddAuthentication.
This is what handles wiring up the ASP.NET Core side of the house.
The ASP.NET or the ASP.NET Core side
is the thing that actually still handles OpenID Connect today.
It's still going to be the thing that handles
your redirect to Azure AD and signing in,
and then handling your ID token when it comes back,
and issuing cookies, and doing all that work.
For sign-in, ASP.NET is still our sign-in thing,
it's still going to do our sign-in for us.
We're going to configure that with lines
32 and 33 that will appear on the screen.
Lines 34 and 35,
that is everything that we need to wire up and
get an MSAL client to handle acquiring tokens,
to handle cashing those tokens so that I can use them later on,
and you as the developer don't have to have
this really deep understanding of the workflow of
OpenID or OAuth 2.0 in order to be able to process that.
In fact, even on line 35,
you notice we say we are using in-memory token caches.
Those in-memory token caches, of course,
they're going to be recycled as soon
as your worker process recycles or whatever.
But if you're using an IDistributedCache in ASP.NET Core,
you can use one of those and plug those in right here.
This will use distributed caches automatically,
you don't have to worry about writing
your own caching handlers, caching mechanisms,
all that's handled for you by the
Microsoft.Identity.Web library that lives on top of MSAL,
so it handles the ASP.NET
configuration and the MSAL configuration,
and then gives you this cool,
really simple API to work with.
>> ASP.NET solves a lot of problems.
If you are working on ASP.NET then that's awesome.
But there's also desktop apps, there's mobile apps,
there's Xamarin, that are all built with .NET.
All these, if they are still using ADAL,
they need to be migrated to MSAL.
We don't have much OAuth-ended web because it is web-only.
But there's much of the then decline,
which is the MSAL equivalent in the namespaces.
They also need to be migrated, not just the web apps.
Just to make it clear.
>> Yeah. That's true. Anything that's using ADAL
definitely needs to be migrated to
MSAL preferably as soon as possible.
We announced the deprecation last summer,
and there is still
lots of apps that are using it and
we're working to try to reduce that number.
The other thing is you may be using it and you don't know it.
You may be using it if you're taking a dependency
on a library or a package that does use it.
Out of NuGet, of course, we've
been taking a look at some of the data out there to
see what packages are still using ADAL and helping them migrate.
It's a lot of first-party teams
here at Microsoft we've been talking to about,
"Okay time to move on over to MSAL",
and so those should start to resolve themselves.
But if you are working on an open-source library,
if you're consuming a library
from a vendor or from another company,
particularly one that maybe isn't super
big where it has a ton of users,
great idea to take a look at that
and see what we can do about migrating that one over,
because this time next year it's going to get a little sticky.
>> Yes. Your apps will still continue working but we would
highly encourage you to move on to MSAL
considering that ADAL will not be getting any updates,
any new features,
and as we said,
MSAL already provides you with a ton of
new capabilities and features that are not part of ADAL anymore.
Where should developers go next?
If they saw this video and they're like, oh man,
we need to start moving asap,
where should they go to make their next steps?
>> We have some new docs,
which is super cool.
We've got some new docs all about migrating
MSAL from or to Microsoft.Identity.Web.
We've got some brand-new docs that are out,
these just came out within
the last six or eight weeks. We've got this one.
We'll have links to these in
the description and we'll also have links on
our blog that we're going to write about this later.
We've got migrating your applications to MSAL and Identity.Web.
Same for confidential client apps for things
like if you've got a console app or if you do have like,
not a desktop app, that would be a confidential client,
but confidential clients where you're using things like
client credentials or other types
of applications that maybe aren't necessarily web apps,
but where you can keep a secret,
Windows services, etc.,
that thing, Linux service that everyone knows about.
We've got a bunch of new docs that are out here.
They're all under this tree of migrating to MSAL.NET.
You can take a look at what the differences are,
especially when you get into mobile.
Mobile gets a little interesting because
there are lots of different interaction mechanisms in
mobile and lots of different expectations people
have for interaction to mobile.
Do I open a system view?
Do I open a web view?
Do I use a broker like the Authenticator app?
MSAL supports
a whole lot more of those scenarios than ADAL did.
There are lots of specifics,
especially around mobile apps
that you can get a closer experience.
Of course, if you're using Azure AD or if you're using Azure B2C,
everything still applies here.
ADAL is going to be going away,
MSAL is the way to go.
Regardless of what app you're using,
we want you to move away.
There are lots of new advantages to
things like authorization code with PKCE,
that's a new flow, that's not in ADAL,
that is in MSAL.
As OAuth 2.1 starts
to get more traction and starts to get ratified,
new grants and new flows start to come out,
all those enhancements and improvements are going to go
into MSAL and not in ADAL.
>> Dynamic consent v2 endpoints and
all the goodness that you would get from the latest and greatest.
Now, if people get stuck and they don't know what to do
next like, "I read the docs but I'm still
not sure what I need to do."
Is there somewhere that they can go to get help?
>> You can come and ask us,
we've got Microsoft Q&A.
Microsoft Q&A, I think it's
a newer thing where you can go and ask questions and get help.
>> It's a new forum, they re-run everything.
It's a new forum where you can go
and directly speak to our support team.
We have 40 engineers, I think,
sitting there waiting to answer your questions to help you out.
But we also have our Discord,
[inaudible]. We also have a stream.
If you actually want to ask questions live to
me and JP about [inaudible] then Tuesdays and Fridays,
08:00 AM Pacific on the 45 Show on Twitch,
you can come and actually talk to us about things.
We've done migrations and will
probably be doing more migrations over
the next few weeks as we try to get more people up to date.
But if you've seen this video,
then at least now you know that you need to start migrating
your apps and benefit from the latest and greatest.
I want to thank JP for coming here,
the links to the repo that JP was showing,
the links to all the migration documents plus
the links to the blog will all be
available at the description below.
Thanks everyone for tuning in and we'll see you soon again.
[MUSIC]