Is there a way to have the Identity Library cookies be tied to the root domain? #58076
-
Hi all; I have a Blazor Interactive Server app that uses the ASP.NET Identity Library for Authentication & Authorization. I have the app set up where you normally connect to it using connect.tradewindsstudios.us. However, it is an app showing events for political campaigns so I also allow connecting using MyCampaign.tradewindsstudios.us where the MyCampaign is a unique Id for a given campaign. It then only shows events for that campaign. The problem is, if a user is logged in to connect.tradewindsstudios.us, they have to log in again to MyCampaign.tradewindsstudios.us. Is there a way to tell the Identity Library to tie the cookie identifying the logged in user to tradewindsstudios.us? thanks - dave |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 2 replies
-
There's a security risk that you should be aware of, which is that if you set the cookie domain to be the parent domain, browsers will send the cookies to ALL subdomains. The risk is that if some other subdomain is hacked, browsers will send session cookies to the attacker - imagine if you're running app1.example.com and app2.example.com, but there's also crappy-word-press-site.example.com that was set up by some marketing team 7 years ago, forgotten about, has never received any security patches and is now taken over by an attacker. Now if a user is logged on and goes to the vulnerable site, their session cookie will be disclosed to the attacker. A better solution is to use a protocol that is designed for single sign on, like open id connect. That said, you CAN control all the cookie attributes like this:
|
Beta Was this translation helpful? Give feedback.
There's a security risk that you should be aware of, which is that if you set the cookie domain to be the parent domain, browsers will send the cookies to ALL subdomains. The risk is that if some other subdomain is hacked, browsers will send session cookies to the attacker - imagine if you're running app1.example.com and app2.example.com, but there's also crappy-word-press-site.example.com that was set up by some marketing team 7 years ago, forgotten about, has never received any security patches and is now taken over by an attacker. Now if a user is logged on and goes to the vulnerable site, their session cookie will be disclosed to the attacker.
A better solution is to use a protocol th…