>> Hi. I'm Jean-Marc Prieur ,
a Program Manager on the Microsoft IoT team.
In this video, I'm going to show you
the code related to authentication in an
ASP.NET Core 2.0 Web API
that accepts token for user signed
in with Azure Active Directory using their work
or school account or their Microsoft personal account.
I'll also show you how a client application uses
the Microsoft authentication library for.NET,
MSAL.NET in short, in order to
acquire a token to access this protected API.
I'm assuming here that you
are familiar with the notion of
Azure Active Directory tenant and
understand.NET Core 2.0 web application Web APIs.
So, what's the agenda?
After a quick intro showing the topology of the samples,
I'm going to briefly demo the scenario,
then I'll show you the code that
protects the Web API and then
the code in the client application to
acquire a token for the Web API.
Finally, I share some resources
with next steps including a link to
the sample using the video and
other samples which will help you go farther,
for instance, to call
the Microsoft Graph from your Web API.
The Azure Active Directory endpoint
lets you sign in users with
either work or school accounts or
Microsoft personal accounts, formerly live accounts.
New this year, you can now use
the Azure Active Directory V2 endpoint
to protect your own Web API
and get a token for your own Web API.
The diagram behind shows
the topology of the sample we'll use in
the demo to understand the code that requires
a token from Azure Active Directory
using an interactive flow,
and then from there,
it will call the ASP.NET to Web API which
maintains a per user list of
items which you can see on the picture here.
So, what code does the magic?
Let's start by demoing
the scenario and we'll see the code.
So here, I've opened the sample in
Visual Studio and as expected from the topology diagram,
there is a service,
the Web API, and the client.
So, let me run them so that we understand
and they expand to the code.
I'm running the service, nothing happens,
that's a service which returns reason, nothing to see.
And by the way, here, we are not
authenticated so it won't give us anything.
So I run this service and I'm already signed in,
so I sign out and show you the sign in experience.
What you will have is to go for is
this dialogue which is
provided by Azure Active directory,
and user, the user you want to use.
So in that case,
I just need to provide the password.
Click the sign-in button,
and we are back in the application,
this pop-up disappears, if you want,
and I can start entering,
"Do shopping," entering a certain number of items,
and this list is maintained really by the service for me,
for the user, "Do shopping, do laundry."
What I want to show you as well is
that if I run a second instance of this application,
so let me run it as well,
I will have now two instances of this application,
this one and this one on top of the other,
and they share the same list.
By the way, this one has signed me not
automatically because there is
a cache and they share the token cache.
The token being what is passed
to authenticate me in the Web API.
So, let's go to the code.
Let's understand what does the magic.
Let's start by the service.
So when my application will call the service,
it will call it into a controller ASP.NET 2.0 controller.
This controller will require
authentication because of this attribute,
"Authorize attribute," and here,
the code of this thing is very simple.
The two method to get the list
and to post the element in the list. This is very simple.
It uses basically your list, your concurrent list,
and it finds from the security token,
from the user which is authenticated in the client,
its find the owner and then it filters
the items for this owner and the controller here.
So, that's how you enter in the application.
Now, how is it that authorize does this magic?
This is because the
ASP.NET Core program start
by coding these start up class,
and this start up class has two interesting section.
The first is this one which is UseAuthentication.
So, we would use authentication.
And here, this configure service
will say, "We use authentication.'
That's a Web API and therefore, will use Jwt,
J-W-T meaning JSON Web Token,
Bearer token to do the authentication.
That means that the API will need it to be called with
an HTTP header containing authorization and
then bearer and then a token provided by Azure Directory.
And this Web API will check that the token is
valid for itself and it does it with this code,
so that is a bit of configuration that is specifying that
in the app settings which is a configuration file,
there is a section named Azure ID and the content of
the sections will go in two options which are here.
Client ID, Client Secrets is not
yet needed for just the Web API.
We'll see how that maps to
the configuration file and the application registration.
So, to show you how that maps,
I've opened here the app
settings.JSON which is the configuration file
and I'm going to jump
to the configuration of my web application.
You'll see that my web application has
an application ID which unsurprisingly,
you find here as the client ID of the application.
Then that is a domain,
so has the domain my company,
and the tenant ID is something which
is for your Active Directory which you know.
That's for the configuration,
and it also needs
to know what will be the URL, the enabled URL.
So in term of platform,
we have here a Web API and you'll find
the scopes which other application can code.
So let me put that a little bit bigger,
and you'll see that this Web API will be accessible
by other as a resource,
and to do something particular,
that's what is the scope on the former API,
the client ID and then access as a user.
So that's for the code of the service.
Let me remove that and adjust to view full screen.
So now, how do we call this Web API?
You've seen all the code that matters for the Web API.
Now in the client,
how do we call this code?
So in the same way we had
some configuration in the service,
we also have some configuration in the client.
The client is another application
which has a client ID but
what I want to show you in
particular is this, to do this scope.
The scope of what we are going to do to
code and this is exactly what I mentioned.
API, the view ID,
the client ID of my service,
and then access as a user.
So, my client accesses
the Web API in the name of the user, for the user.
Then, how do we do that?
So there will be two steps.
The first is acquire token and the
second is call the Web API with a Bearer token.
So, how do we get a token?
We use my MSAL, Microsoft Authentication Libraries,
and in this case,
we have a desktop application
so it's a public-client application.
You recognize the configuration
which was in the config file.
You see the action of the
token cache which I mentioned when
I instantiated two instances of this application.
And from this app,
we will get a token.
We will get a token by this pattern which is, first,
try to get it from the cache by
coding AcquireTokenSilent,
and then if that doesn't
succeed in this case of this application,
we decide to show the "Sign in" button.
Sign in first and then enable the "Sign in" button.
So how do we get this
token if it's not already in the cache?
Then, we'll go in this method and sign in.
I will find the sign in method.
In this sign in method,
I will this time do
an AcquireTokenAsync which is interactive.
By the way, I will force the application
to show the select account dialogue.
So that's why you could see
that I could choose between several identities.
Then the last part is how do I call the API?
So coding the API is done in the
in the same code as here.
So when you get what you get from
AcquireTokenSilentAsync or AcquireToken is
an authentication result, as you see here.
And authentication results has a certain number
of members including one which is the access token.
And by this line,
I'm creating an authentication and
authorization there
with the value bearer and the access token.
I will add that to the HTTP client,
and then I can code
my API which is the base address you've seen,
and plus API to do this.
That's classical.NET Core Web API and that's it.
That's the way you provide
the authentication of the user to the Web API.
So, what did we see?
We've seen that Web API can accept
bearer tokens and verify that they are void.
Then, we've seen how
a client application can use this bearer token.
The last thing I want to show you is
here in this code, this is tentative.
We have done it for specific tenant,
and that's a line of business application.
If you just change that, then now,
you accept any identity
and then you will also have to do
that because that's not specific to a tenant,
and of course, you would probably
want to do a bit more which
is implement the user validator which is a delegate.
So I'm not going to do it but I'm just giving
you some leads on how you would do it.
That's it.
So that's it for the demo,
I hope you found it useful.
We've explored the most important part of
the code to protect V2 Web API.
We've also seen the code in
a WPF client to acquire a token and call this Web API.
We've seen that both applications need to be
registered with Azure Active Directory V2 endpoint,
and we've seen the code to configure them accordingly.
To conclude, here are
some resources you can follow to find information.
I encourage you to go for
the sample yourselves and learn how to recreate it.
I've also included samples which will take you
from this point to calling the Microsoft Graph,
a link to our documentation,
and a link on how to get help,
ask question, or post suggestions.
Thanks for watching.