0

As far as I understand, Identity sends to the user an encrypted token with some user information like the user name and expiration date. Then, when a new request arrives to the server, it decrypts it and will have available all the user claims and some other information.

My question is, in case there is no need to send the authetication information to other servers (for example if you are authenticating against another web site) would it be more safe not to send as much information to the user? Perhaps we can just send a large code to the user and then match it with an in memory collection or database.

I know that if someone is able to intercept that code she will be able to also make valid requests, but when the "ticket" expires it will not longer be valid for anyone until making the login process again. However, if that code is compromised there won´t be any other information than that.

I hope I am being clear with my question, if not, please let me know it so I can improve it.

Ignacio
  • 123
  • 4
  • I am afraid I do not understand the use case you have mentioned: "in case there is no need to send the authetication information to other servers (for example if you are authenticating against another web site)". Can you explain more? – Bartosz Rosa Apr 20 '20 at 21:08
  • Thank you Bartosz! I mean that if your authentication mechanisms uses JWT for example I understand that perhaps is useful to send information in the token itself and not just a code. However, if ASP.Net Identity will just autheticate with your backend why not just send a long truly random code to the client and then retrieve the necessary information from database using that code. Am i clear now? Thank you very much! – Ignacio Apr 20 '20 at 22:17
  • I will just reference a question to clarify concepts if anyone get confused: https://stackoverflow.com/questions/23758704/asp-net-sessionid-vs-aspxauth-why-do-we-need-both-of-them – Ignacio Apr 25 '20 at 15:54

1 Answers1

1

DISCLAIMER: I am not a Microsoft employee and I do not know the exact causes of presenting ASP.NET Identity. My opinion base on documentation and some practical experience.

The main purpose of presenting ASP.NET Identity by Microsoft was to make the authentication mechanism more generic, reusable and testable. There also show up some new ways of user authentication using social media which have happen to be more and more popular and would be nice to support. To achieve those goals some standard behaviors have been implemented in library like Cookie-based authentication (using OWIN middleware), where some user data are put into the encrypted token and provided as authentication cookie.

I think that you are correct in your exact use case. But thinking of different scenarios that ASP.NET Identity can be used, you can use the same code and same mechanism (after some easy reconfiguration), which means that it is quite easy to change the behavior of an application.

If you would like to change authentication mechanism to your idea, you still can do this without breaking the rules of ASP.NET Identity. The only you have to do, you need to implement some interfaces presented with ASP.NET Identity and add this to your app stack.

Bartosz Rosa
  • 337
  • 1
  • 6
  • So we could override the behaviour of the ASP.Net Identity and take out all the data from the encrypted token and just put there an unencrypted long enough code in order to validate it against our database and retrieve from there the user and session information? Do you think it´s an alternative method that could work instead of default ASP.Net Identity that stores things like username encrypted in the token stored as a cookie in the web browser? – Ignacio Apr 22 '20 at 15:28
  • I believe it could work, but as everything "the devil is in the details". One thing to consider is performance. I suppose that additional calls to database can cost more time than just decrypting and parsing token. The second thing is the database security. Generally you have to analyse pros and cons of solution in regards to invested costs (time, money). – Bartosz Rosa Apr 22 '20 at 22:53
  • Of course, you are right. However, I think that send sensitive information to client could not be a good idea every time. As you said, we have to analyze pros and cons. – Ignacio Apr 22 '20 at 23:02