'SSO using Azure B2C with multiple custom policies with different domains
I have been several weeks on this now. I need to achieve the next scenario with Azure AD B2C custom subdomains: for example, having ssositeA.mydomain.com with custom policy b2c_1a_signin_siteA and ssositeB.mydomain.com with custom policy b2c_1a_signin_siteB and when signin in SSO for siteA get signed in to siteB.
I've tested and that's not at least the default behaviour. Having a central sso works: for example, sso.mydomain/<tenant id>/b2c_1a_signin_siteA and sso.mydomain/<tenant id>/b2c_1a_signin_siteB. But, it's not ideal since we would like to have a branding related name in the subdomain.
The cookies are saved with the full subdomain:
.ssositeA.mydomain.com
.ssositeB.mydomain.com
Is there a way to indicate that for ssositeA and ssositeB the cookies be saved at the domain level, so we would have
.mydomain.com (as cookie's Domain)
and we can have shared the session between the two sign in sites?
Solution 1:[1]
• Yes, you can surely save the cookies at the domain level rather than issuing cookies for every subdomain for SSO even though the root domain for those subdomains is the same. According to RFC 2109 and RFC 6265, if the domain name in your cookie's domain parameter doesn't start with a period, then it will not let subdomains read that cookie and if it does start with the period, then all subdomains will have full access to that cookie's value, i.e., a Set-Cookie from request-host ‘subdomain.myserver.com’ for ‘Domain=.myserver.com’ would be accepted wherein the origin server's fully-qualified host name must domain-match the Domain attribute of the cookie.
Thus, by setting the Domain property of the cookie in the header to the domain of the sub domain, in this way you instruct the browser to send the cookie to all sub domains as below: -
Response.Cookies(“UID”)=1
Response.Cookies(“UID”).Domain = “.myserver.com” ‘
Also, you can set the ‘Domain’ attribute present in the header as below: -
Set-Cookie: name=value; domain=.mydomain.com
Note: - The domain attribute must domain-match the request URL for it to be valid, which basically means it must be the request domain or a super-domain. So, this applies for both examples in the question, as well as sharing between two separate subdomains.
For more information regarding this, kindly refer to the links below: -
Sources
This article follows the attribution requirements of Stack Overflow and is licensed under CC BY-SA 3.0.
Source: Stack Overflow
| Solution | Source |
|---|---|
| Solution 1 | KartikBhiwapurkar-MT |
