In this video, learn the protocol flow for a native app.
- [Narrator] Now let's understand how the protocol flow works before diving into code. At the left-hand side you have a native application and it's going to call a web API, in our case Microsoft Graph. And there are important endpoints to understand here. The authorization endpoint is where the user writes their credentials and also you get the authorization code from. And the token endpoint is a different endpoint where our application will use the refresh token to get an access token from.
So let's understand this. You start your native application, the user clicks on the Sign In button. At this point, your native application is expected to launch a hosted browser window. Why browser? Now this is a common request a lot of people have. Why can't I provide my own login user interface? The thing is, as your AD is extremely flexible, different clients may have configured it differently. You may be using ADFS, somebody else may be using something else.
The only way we can guarantee that their login fidelity and rules are respected, is to show their login UI. Therefore, it has to be in a browser. Technically you could get around that limitation, but I won't recommend doing that. So you request an authorization code, so a browser pop up comes up, the user provides their credentials, and you get an authorization code. Now you need to call the web API, so with the authorization code you request for an access token.
Azure AD returns to you an access token for the specific resource you have asked the access token for. And now with that access token you are able to call the web API. And the web API, assuming that the access token is valid, the web API responds positively. Great! What happens when the JWT token expires? Your access token is good for only let's say an hour. So then what you do, is that same refresh token that you had earlier, you would have, at this point, saved it in a token cache.
And actually, adal.js just does this for you so you don't have to write any code for this. So using that refresh token, using a method called, "acquire token async silent" you will basically say that for this resource ID, without showing the user the login dialogue again, I'm asking for a new access token. Right? So the first time you login you say, "Acquire token." And the second time you login, using a refresh token, you say, "Acquire token silent." We'll see this in code shortly.
The pattern is that if you're required to call sign in fields for any reason, let's say the refresh token is no longer valid, then you want the user to sign in again. So you usually put that in a try catch block. Assuming that the refresh token is valid, you return an access token and then you put that access token on top of your request and you continue making request, and this can go on for months without the user having to sign in again. And that's the true beauty of native apps, that they can be very long lasting because they have the ability to use refresh token.
Sessions are maintained using refresh tokens.
- What is Microsoft Graph?
- Registering a web application in Azure AD
- Adding authentication logic and authentication UI
- Native applications calling Graph
- Reviewing scenarios where web apps involving Graph are useful
- Web applications with application identity and delegated identity calling Graph
- Daemons calling Graph