In this video, learn why you need TokenCache, and add to your project, and use TokenCache during the sign in process when you receive the authorization code.
- [Instructor] So in order to make our application work with delegated user identity, I need to make some changes to my application. Well, as I mentioned earlier, one of the things that I need is a token cache. Now this token cache is something that should work with a website. It needs to maintain pull user sessions on the server. Now since this is a demo, I'm going to create a very simple token cache. Let's call it dictionary cache.
And the concept of this token cache are exactly the same as what we saw in the native client application, except over there we were storing the cache in a encrypted file. Here, well this is demo code so I'm keeping it simple. Everything is being stored in a static dictionary. Now, this is demo code. That's a very important point. Because with every I S reset, the static dictionary will disappear. You probably don't want that to happen.
Technically, you would probably want to store it at least in session or ideally in a backend sequel server or some sort of store. Yeah, you can do all of that in real production applications. But, that would unnecessarily complicate what I'm trying to convey here. That really all we need is a space on the server that is pull user. That is why in this dictionary cache constructor, I'm accepting the user ID as a constructor. And if you go through this code, it's exactly the same as before. You know, after access notification before access notification, and I'm just storing the tokens as they come.
As you can see over here, right. This is exactly the same as the cache that we wrote for native client apps, except there is no encryption here, there should be, that's good practice. And also instead of storing it in a file, I'm storing it in a in memory object, that is delineated by pull user. Okay, so my cache is done. Now, let's make user file. Next, let's go to start dot cs, and here, let's go down to where the authentication occurs.
So you see here, there's authentication failed even that we're handling. I'm going to handle one more event now. Which is authorization code received. Which is also the same as authentication succeeded. And I need to add a using for these red squigglies to go away. So basically what we're doing over here, is that we're saying, that when we get the authorization code, as in that a successful authentication has been done. At that point, go ahead and create a client credential.
You know with the app side, fill that app key in a moment. And get the user object ID, which is based on a claim. And then based on that we initialize the dictionary cache and we pass the newly created dictionary cache to the newly created auth context. And then at the same time because the user is already logged in, at this point we have everything we need to go ahead and create an authentication result for Microsoft graph also.
Why did we do this right now? Why don't we do this when we actually make the call? The answer is you could do it when you make the call, but we already have everything we need to get the refreshed token. So I went ahead and created it over here. Let me go ahead and fix this app key as well. And then we can go ahead and start making changes to our controller. So the app key is simply reading from the configuration file And I'm just going to call this variable app key as I've used it below.
And this will be the dark config setting that I had over here. Let's go ahead and place that in my code. Great. So this point my authentication code related changes are done. Next we'll see what changes we need to make to the controller.
- 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