Welcome to the next video in the FTA for ISV Series - Identity for multitenant applications
Identity is the corner stone of working with your external customers
Today we will cover some core concepts in applications, things to
consider for multitenancy and how to get started.
In today’s session we will be starting off with an overview of the Microsoft
Identity Platform. Then we will go over managing external
identities, which is key to your experience as an ISV
We’ll move on to Multi-Tenant Application Types in Azure
Then wrap it up with building SaaS applications with Azure AD
So without further ado, let’s get started.
So let's take a step back and take a 30,000 foot view of
the Microsoft identity platform. The Microsoft
Identity platform implements authentication and authorization using
two industry standard protocols - Oauth 2.0
and OpenID Connect. Theres four main components of any Oauth platform.
The first part we'll talk about is the authorization server. The authorization server
is responsible for ensuring users identity and granting or revoking access.
It exposes a couple of end points that'll vary, which we'll talk about that in the future, that
you use to authenticate users to your system. The other component of the identity platform is the resource owner
which is your end user or customer. So that’s basically a user or tenant that youre going to allow access
is to the resources or data within your application for. The third is the Oauth client.
Its identified by an application ID and the app id is created using something called the app registration
which we will talk about in the next slide. The Oauth client is actually whats going to be interacting between your
end user and the resources that end user is trying to access. For example we have the end user
that is trying to access data. Theyre going through this web application. The way they access data
through web app is via a bearer token which essentially provides an light weigh security token telling everyone
who I am and what I have access to. The fourth component is the Resource Server
(REST API). That rest API or backend server or whatever resource that user is trying to access
will present that token via the web application and then that resource In the back will accept it and say
"hey, this user is someone that I'm familiar with and has the proper roles that are allowed to access this resource."
Or on the contrary say, "this resource doesn’t have proper authorization to access this resource."
So that’s identity at a high level. Now we will move on to how these components are actually working.
Your application accesses everything using whats called an application registration.
Within the app registration you define the identity configuration. So you can do things like define whether
it’s a single tenant vs multi tenant type of application. You can also set things like scopes
Scopes allow you to secure different parts of your application and allow users to access different parts of your application based on
those boundaries. So you can define a scope called User.read and that would allow a user to have read only
access to an application. Whereas you can define a scope like User.Admin and that would allow the user
specific access to more administrative parts of your app. In addition you can define scopes
or your back end as well as application roles. If you want a more in depth review of scopes, you can refer to the Governance
session in our series. So now lets take a quick look at the azure portal so you can see what an application registration
can look like within your tenant. Here we have an azure active directory tenant;
and under the Azure active directory tenant I have whats called an app registration as previously mentioned.
Here you can create new app registrations and monitor previously created ones. What I will do right now
is walk you through an existing app registration so that you can see all the bits and pieces that are involved.
This can be found in the Azure portal in the App registrations section, which you can type in the search bar.
So first thing you want to take a look at is the Application (client() ID. This is
the unique identifier for your application that is in your azure active directory and will be used to access different back
end components. Theres also an ObjectID that’s created. All objects in Azure AD
have an object ID. When you're making an API request to address a specific Application object,
you would use the object ID: An Application object's object ID is only relevant in
the same tenant where the app is registered, and is only ever used to identify that object.
So one thing I can actually do once I log into my app registration is define the different account types that can be accessed through
this app registration. For example I can say I can only authorize access to accounts
within my own organization directory. For example you can see here that theres an option that only people
within my own organizations directory can access this. This would make the application
single tenant. On the other hand you can allow any organizational directory within the azure active directory
to access it and that paves way for a more multitenant application. I can also make that a
little more fine grained, and control it so that only certain azure ad tenants can access this. But the first thing
you'd need to do is enable that multitenant setting then you can start to get more granular. Theres a couple of
ther things on the screen worth bringing your attention to. When your application is making a request for that bearer token from
Azure AD on your behalf, the application is going to redirect to another end point. So take the time to
identify some end points you'd want to use for redirect and possibly for testing. The Microsoft identity
platform endpoint allows work and school accounts from Azure AD and personal Microsoft accounts (MSA), such as hotmail
outlook, msn, etc to sign in. The other thing you want to make sure to look at is what sort of tokens do you want to
look at to request back from Azure AD when youre authenticating the user. Access tokens are used
bearer tokens. A bearer token means that the bearer (who hold the access token) can access
authorized resources without further identification. Because of this, it’s important that bearer
tokens are protected. If I can somehow get ahold of and “bear” your access token, I can pretend
to be you. The ID Token is a security token that contains
Claims about the Authentication of an End-User by an Authorization Server when using a Client, and potentially other requested
Claims.(claims are name/value pairs that contain information about a user).The ID Token
is represented as a JSON Web Token. identity information about the user is encoded right into the token
and the token can be definitively verified to prove that it hasn’t been tampered with. So do you want to use access
tokens which are used for implicit flows which we will talk about in a little bit or do you want to simply request ID tokens.
One more thing to take a look at under application registration, are defining API
permissions. Here you can see what I've done is say that for this app registration I want to request certain permissions
on the user 's behalf. So if you ever logged into an application on Azure AD you see for the
first time theres this consent that needs to happen. So for my application I'm saying this app needs to use Microsoft
Graph and ive identified a couple of scopes underneath Microsoft graph which include reading email, profile and using
User.Read. So essentially what I'm saying is my application needs to request permission and at some point
during my application I'm going to need to call Microsoft Graph on behalf of this user. I can also do
additional permissions; theres several you can look through for different APIs available within Microsoft.
I can also can request permissions for APIs that I've created myself. So for APIs that I've created
myself the way I want to do that is through scopes which we mentioned previously. So what I can do here is
add a scope. I'm going to define the URI so it gives you an api/<yourappID>. Then define
the actual scope so I can name it something like app.read. Decide who can consent
And then this text is just text the user can see whenever the scope is being consented on their behalf.
So then you add scope and press continue. Now you can request permissions for API's that you've
personally created. Another key concept to understand within application registration
is application roles. Application roles are usually defined on an application
registration representing a service, app or API. When a user
signs in to the application, Azure AD emits a roles claim for each role that the user or service
principal has been granted. This can be used to implement claim-based authorization. App roles can be assigned
to a user or a group of users. App roles can also be assigned to the service principal for another application
or to the service principal for a managed identity. Now that we've talked about application registration, let's
move on to the next crucial part of identity on Azure. So another thing that I'd want you to keep in mind are the various types
of Oauth flows. There are a few types of authentication flows that can be used based on the type of app you are building
and what youre desired state is. I will do a quick run down of each so get ready. The first we will talk about
is Implicit Grant - The Microsoft identity platform supports the OAuth 2.0 Implicit Grant flow as
described in the OAuth 2.0 Specification. The defining characteristic of the implicit grant is that
tokens (ID tokens or access tokens) are returned directly from the /authorize endpoint instead of
the /token endpoint. This is often used as part of the authorization code flow, in what is called
the "hybrid flow" - where you're retrieving the ID token on the /authorize request along with an authorization
code. The implicit grant is only reliable for the initial, interactive portion of your sign in flow,
where the lack of third party cookies cannot impact your application. This limitation means you should use
it exclusively as part of the hybrid flow, where your application requests a code as well as a token from the authorization endpoint
This ensures that your application receives a code that can be redeemed for a refresh token, thus ensuring your app's
login session remains valid over time. The next we'll go over is AuthCode
This can be used in apps that are installed on your device. They're typically used for things like web API and web applications
so your Single Paged Apps or native apps are going to use AuthCode grants. This allows apps
to acquire access tokens which can be used to access resources secured by the Microsoft identity platform as well as
refresh tokens to require additional access. The next we'll talk about is On-behalf-Of. This flow
serves the case when you want to have a service or web API that’s trying to access another service or web API. So the idea
here is delegating identity and access between those 2 services. Next we have the client credentials.
In the client credentials flow, permissions are granted directly to the application itself by an administrator.
When the app presents a token to a resource, the resource enforces that the app itself has authorization to perform
an action since there is no user involved in the authentication. Because the application's own credentials are
these credentials must be kept safe - never publish the credential in your source code, embed it in web
pages or use it in a widely distributed native applications. Finally we have device code
this allows users to sign in using input constrained types of application, like an IoT device. You can also
use AZ login using our Azure command line and get redirected to a web application or our site where you
have to enter in a code. This was a quick run down of the authorizations available , for a more in
in depth look, visit our Microsoft Identity Platform docs. This wraps up our first portion of the presentation
We talked about the Microsoft Identity Platform all up, Application Registration and Oauth flows.
In this next part of our session, we're going to cover Managing external identities. Azure provides a couple of ways
to manage external identities or users and I will use this section to highlight those two concepts and talk about when you should use what
See you there!