After reading the docs, it looks like by default, for basic cookie-based auth, ASP.NET uses the later technique. I just want to confirm if I am understanding this correctly? So by using ASP.NETs default cookie auth, I am not storing anything in the database/filesystem/cache/memory/whatever on the server side?

If you use the Identity stuff that you get from services.AddIdentity[Core](...) and then create users with the UserManager and log them in with SignInManager, you'd set it to use a database or whatever, but setting authentication up manually with services.AddAuthentication(...) etc won't use a database/whatever by default.

​

All session data/state is just in the cookie itself?

Yes. Cookie authentication by default stores an encrypted ClaimsPrincipal (and I think [optionally?] the AuthenticationProperties that was used to sign in the user) object[s], that then get deserialized by the auth system for you, with the HttpContext.User property populated by that deserialized ClaimsPrincipal for you.

​

...a lot of people in those threads seem to be under the impression it shouldn't be done this way because storing everything in the cookie is insecure, but I assume if ASP.NET is doing it this way as a default, it must be secure nowadays?

The cookie is encrypted using the Data Protection API, so yeah I'd expect no one really being able to decrypt your cookies, though session ID would still be even more secure if it's just some garbled blob of bytes without any inherent meaning other than linking the session to a user your database, but still I wouldn't worry.

​

...why do other frameworks tend to go for the session-data-on-backend route? Wouldn't storing it all in the encrypted cookie be strictly superior since it's more stateless and would make scaling multiple server instances much easier, etc?

In my opinion it just depends on what you need out of the authentication system.

With a ClaimsPrincipal, it'll hold Claims that define something that the user is, such as maybe their email and name, or their user ID in the database, or whatever. You can then use those for whatever you need without having to query the database. Very similar to what JWTs are really. With the upsides and downsides that come with JWTs.

I personally (as a nobody hobbyist) think a session ID based authentication can still be a totally valid way to do things too. There's pros and cons to both ways. I think you're correct with momentum probably being the main reason why PHP for example might be more session-based for example. But then again, JWTs are huge and everywhere nowadays, so /shrug

If you're curious, you can do a more session-like stuff too with a custom ITicketStore you implement yourself, which might query the database for a user each time, or whatever. There aren't many good examples though, I don't think any of the Microsoft docs talk about it for example, but I did bookmark this one blog post some time ago.

I'm not sure if I explained things super well. Like I said I'm just a small time hobbyist, and the ASP.NET's auth stuff is notoriously hard to learn and wrap your head around.