2

First of all let me apologize if what I am asking here does not make much sense. Also, thank you for your time. This is my first time righting in here so I hope I do it right.

I have been developing in Asp.Net for a year now, and we used the Session to keep the user data persistent throughout that user session (Like Email, Name, Phone, Company, etc..). And if I'm not mistaken that information was hidden, there for not in a cookie and not visible in the browser.

Now we are starting do develop in .Net Core 3.1 and I'm in charged of recreate the login using this new framework, with the condition that the persistent user data is not stored in a cookie or not visible to the browser, it needs to be safe and hidden.

I have looked in the .Net Core Session and the Auth Cookie, but for both of those options we create cookies that hold all that information in, in both this approaches is the information secure or is vulnerable?

After a while I came across this area in the Microsoft docs: Introduction to Identity on ASP.NET Core

My question is if I go with this approach can I accomplish what I want, have persistent user data not in a cookie or not visible to the browser. If what I'm try to accomplish is not possible and a cookie needs to be used, is there a way of keeping that data save and secure? Or is there another approach to keeping data across the session secure and not visible to the browser?

EDIT: To give a more practical example, in our dashboard we will filter the data depending on the user, more precisely his type, Company, Area and Channel, this are attributes of every user. When a user logs in and is redirected to the Dashboard he will only see the data that as the same attributes as him. In Asp .Net all I needed to do was save that information in the moment of login inside the Session and then retrieve it when I needed them. In .Net Core, I have been able to it in 2 different ways, the first was to use the "HttpContext.Session.SetString()" and "HttpContext.Session.GetString()" to save and retrieve the data I needed. The second way was to pass the data inside the Claims when I do "HttpContext.SignInAsync(CookieAuthenticationDefaults.AuthenticationScheme, new ClaimsPrincipal(claimsIdentity), authenticationProperties);". Both of this approaches allows me to fetch the information I need and use it. But all the data is inside cookies, visible in the browser.

But For what I'm understanding .Net Core does not allow to save data like that on server-side, so is possible to encrypt the auth cookie so the data stays protected.

My code to login the user is as Follow:

After I authenticate the user I run this to login the user and create the auth cookie.

string userGUID = Guid.NewGuid().ToString();

List<Claim> claims = new List<Claim>()
{
    new Claim(ClaimTypes.NameIdentifier, userGUID),
    new Claim(ClaimTypes.Role, "Admin"),
    new Claim("Company", "User Company"),
    new Claim("Area", "User Area"),
    new Claim("Channel", "User Channel")
};

if (claims != null && claims.Count > 0)
{
    var claimsIdentity = new ClaimsIdentity(
        claims, CookieAuthenticationDefaults.AuthenticationScheme);

    AuthenticationProperties authenticationProperties = new AuthenticationProperties
    {
        IsPersistent = false,
        AllowRefresh = false,
        ExpiresUtc = DateTimeOffset.UtcNow.AddMinutes(30)
    };

    _httpContextAccessor.HttpContext.SignInAsync(
               CookieAuthenticationDefaults.AuthenticationScheme, 
               new ClaimsPrincipal(claimsIdentity), 
               authenticationProperties);

}

Once again thank you for your time and please tell me if there is something that I can do to clarify this question.

Rui Filipe
  • 43
  • 7
  • My guess is your legacy Login may have used some mechanism similar to a cookie. Session (wich are stored server side) are kind of deprecated because of multi-frontend scalability problem. If you need to store sensitive data on browser you can imagine a system to encrypt them server side with a non symetric algorythm as long you don't need this data in client-side. An exemple of data usage scenario could be helpfull to better target your needs. – Guillaume Raymond Jan 15 '20 at 15:04
  • I thank you for the reply, so for what I can understand I can no longer store and access data in server side the same way I could in Asp.Net. I Edited my question to have more information. Can You give me a example on how to encrypt the cookie? or is it automatically encrypted and secure? I'm sorry for all the questions, it is my first time trying to create a safe login from the ground up. – Rui Filipe Jan 15 '20 at 17:03
  • Just another question : Is user can use external authentication provider like Facebook, Google and so on ? – Guillaume Raymond Jan 17 '20 at 12:03

1 Answers1

1

First I've not done yet Authentication in .Net Core but I far I as know and if I was in your case I will try to use OpenId like per MS recommendation you had mentionned.

If your users are not authenticated by an external provider like Google, Facebook, etc... you will have to create your own Oauth2 Authentication server. A thing I did back in 2016 but in .Net Framework 4 not .Net Core. However while it's still possible today, I will not recommend to invest in .Net Framework as .Net (Core) 5 will make it outdated in Nov 2020. But for your information you can refer to this answer here: How to implement oauth2 server in ASP.NET MVC 5 and WEB API 2 [closed]

If you want to go on creating your own OAuth Provider I suggest you look at this answer here : OAuth Authorization Service in ASP.NET Core

My though with the "cookie" is it could only store the Authentication token. I mean the OAuth server provides a token each time a user authenticate. This token should be valid for a defined period of time (let's say 20 min). Then this token is invalid after.

To keep user connected you will surely have to implement a mechanism to automatically renew it. Let's say the token is valid for 20 min if the server received a request while the token is still valid but only for the next 10 min then the server ask the OAuth provider to renew it and give it back to the browser in order to update his "cookie".

As far as I remembered we only used Http Header Authorization field (and no cookie) to send the token on each request and handle its lifetime (expiration/renew) in the browser using javascript ajax request and local storage.

Guillaume Raymond
  • 1,476
  • 1
  • 18
  • 32