Authentication in an ASP.NET web application using Azure AD

Question

I'm looking at using Azure AD to handle user accounts for my Web App.

I've implemented something similar to Microsoft's sample code shown here (Linked from here ).

It uses the following authentication scenario (this) :

As far as I understand it, once the the user is authenticated, OWIN creates and sets its own session cookie for the specific domain. As long as this cookie hasn't expired or become corrupted, the user will stay logged in. Our app only ever talks to the authentication provider when a user logs out or logs in again.

So this raises the question: What happens when a user is deactivated, or deleted, from the AD while they are still logged in?

Let's say I have some sensitive information stored in my web app's database that is only modifiable by authorized users. The permissions for authorization are kept in a local database which is keyed to the user's OID.

Bob is an administrator for our company's Web App. For reasons undisclosed, we have had to terminate his employment. Our domain administrator locks his AD account out and Bob is escorted out of the premises. Everything should be fine.

Everything is not fine.

Disgruntled Bob arrives home and looks at his laptop, his browser is open on our web app. He thinks, "Surely it must have been locked out?". He browses to the Administration part of the site and sees he is still able to access it. In a petty way to get his own back at the company, he goes in and modifies some of the sensitive information.

Bob is still authenticated (Bob's credentials still identify Bob), but he should no longer be authorized to access the service. However, the session cookie is still valid . Bob is still logged in and can still has access the web app until this cookie expires, or until he ends the session.

How can I stop this from happening? (Besides not sleeping with Bob's wife.)

A few "solutions" I have thought of:

1. Call to Azure's graph API for every [Authorize] action, which returns whether the user is valid and is not locked out. Then make the user end their own session .

2. Call to a user metadata table on the application for every [Authorize] action which checks if the user is disabled or not. (Not ideal: Disparity between AD and local DB)

3. Use BearerAuthentication some how. (Help with this would be greatly appreciated, the only examples I can find are for web-api)

4. Do nothing and deal with this unlikely situation (Not ideal)

Answer 1

As long as this cookie hasn't expired or become corrupted, the user will stay logged in.

Not true.

Both OAuth2 and WS-Fed tokens contain the token expiration date among other attributes.

Thus, in reality, Bob will be able to use the application until the expiration date in the token passes. Usually token providers issue tokens that are valid for few hours at most.

Answer 2

You can make the token info in the cookie expire quickly, say every half an hour. Behind the scenes, you can use the refresh token to get new credentials, so users aren't inconvenienced. You could do this in a httpfilter. If a user has been removed from AD, the refresh operation will fail. This lessens your window of vulnerability. I suppose you could even shut that window down to a few minutes.

You might also force token refreshing before sensitive operations.