1

I'm building a new Web API application using OWIN cookie authentication (ASP.NET Identity 2.2) for security.

I'm new to the whole cookies thing, but I've got a head-scratching problem: How is a logged-in user immediately blocked from using the API if their account has been deactivated (either deleted or locked-out)?

This arises after a startling discovery that if I have a user logged in on a client app, and I delete their user account via a different app, they are still able to access the API (i.e. the [Authorize] filter still succeeds because their cookie is still valid).

Somebody please correct me if I'm wrong, but AFAIK, cookies are not stored on the server, so there is no way to "invalidate" the cookie.

Yes, if the user logs out, they won't be able to log back in again. Also, I understand that setting an expiry on every cookie upon successful login will mitigate the problem.

But what about the following scenario: a system administrator (let's call him JoeAdmin) gets fired or otherwise becomes untrusted and some other administrator locks out his account. If JoeAdmin happened to be logged in when he got fired and became disgruntled, he still has access to the system and can do some real damage.

In this scenario, how could JoeAdmin be blocked immediately?

BCA
  • 7,776
  • 3
  • 38
  • 53

1 Answers1

1

JoeAdmin happened to be logged in when he got fired and became disgruntled

Also JoeAdmin could have saved the cookie value offline, awaiting for his account to be revoked, and then later restores the cookie value to his browser.

OWIN cookie authentication is not ideal if you ever need to immediately invalidate logins.

This is because all the state information about the user is stored client-side, authenticated with a secret only on the server-side.

That said, you could do something with Oauth2 refresh tokens like here. e.g. have an access token that expires after say a minute, which when expired the application has to use a refresh token in order to gain an access token for another minute.

This way, any revoked accounts are only exposed for a short time. However, you may need to deal with the complexity of out-of-sync clocks on client and server.

Long story short, if you need to secure your system in this way, traditional server-side tokens would be the way to go. They are more secure in this regard.

The risks with using OWIN cookies are very similar to those of using JWT's for authentication. See this comment and the associated question and answer.

Community
  • 1
  • 1
SilverlightFox
  • 32,436
  • 11
  • 76
  • 145
  • Thanks for confirming my suspicions. I have an idea which I tested and which seems to mitigate the issues for my particular scenario: Setup my client apps to poll a "/VerifySession" endpoint every 5 minutes. That endpoint performs database checks like user still exists, not locked out, etc. If these checks fail, it does a `SignOut()` thus invalidating the cookie on the client. Yes, it doesn't stop some savvy user from using Fiddler, but takes care of 99% of the cases. What do you think of this approach? – BCA Jun 16 '16 at 15:53
  • As you say, it does not prevent a savvy user from bypassing your check, and is therefore insecure. You have to assume that any JoeAdmins that are clever enough to store their cookie for when they get fired, will also be clever enough to discover how your app works should they be motivated to use it for evil. – SilverlightFox Jun 16 '16 at 16:03
  • @BCA. In addition, `SignOut()` only deletes the client-side cookie. JoeAdmin will simply restore his cookie to the browser again. – SilverlightFox Jun 16 '16 at 16:09
  • True, but as you said, there is already inherent insecurity in using client-side cookies. I'm hoping that my approach will improve on that. Specifically, I'd like to eliminate the case where some non-savvy user discovers that, even though they got fired, they still have access to the system because they left the client running. – BCA Jun 16 '16 at 16:11