#TL;DR
As founded by OP and answered here, he is falling in another case than the ones myi nitial answer was addressing. His case implies CORS, and probably a preflight request. Then his case can be handled by adding the Access-Control-Allow-Credentials in the resource preflight response and in the Set-Cookieresponse too. It seems to overrides the Cookie rules I explain below.
Here is my old answer, still true but not explaining the whole thing:
Microsoft has banned cookies on azurewebsites.net top domain by including it in public suffix list.
#Full details
According to RFC 6265, setting a cookie for your site top domain is supported:
The user agent will reject cookies unless the Domain attribute specifies a scope for the cookie that would include the origin server. For example, the user agent will accept a cookie with a Domain attribute of "example.com" or of "foo.example.com" from foo.example.com, but the user agent will not accept a cookie with a Domain attribute of "bar.example.com" or of "baz.foo.example.com".
So, if your set-cookie on domain yourdomain.net occurs from a request on a yourdomain.net sub-domain, this cookie should be accepted.
And as written a bit above:
The Domain attribute specifies those hosts to which the cookie will be sent. For example, if the value of the Domain attribute is "example.com", the user agent will include the cookie in the Cookie header when making HTTP requests to example.com, www.example.com, and www.corp.example.com.
So your accepted cookie should be sent to any subdomain of yourdomain.net on subsequent requests.
But as per §5.3, point 5, a domain being a public suffix should be ignored if the http hostname does not match it entirely. (Following this rule depends on client choices and configuration, but browsers usually follow that rule.)
5. If the user agent is configured to reject "public suffixes" and
the domain-attribute is a public suffix:
If the domain-attribute is identical to the canonicalized
request-host:
Let the domain-attribute be the empty string.
Otherwise:
Ignore the cookie entirely and abort these steps.
Public suffix list handled by Mozilla does list azurewebsites.net.
// Microsoft : http://microsoft.com
// Submitted by Barry Dorrans
azurewebsites.net
azure-mobile.net
cloudapp.net
So, and that is quite logic, Microsoft has actively banned cookies set on azurewebsites.net from sub domains.
Addressing OP findings and own answer:
Due to azurewebsites.net being in public prefix list, Set-Cookie on azurewebsites.net from a azurewebsites.net sub-domain should be ignored.
But if the response setting the cookie include additional CORS headers (Access-Control-Allow-Credentials along with more classical ones) allowing explicitly credential sharing, the CORS header seems to take precedence and causes the browser to accept the cookie even on public suffix.
I was unfortunately unable to find any spec about that behavior. If "CORS header allowing something forbidden by cookie rules" is actually an unspecified case, this may change, and it is then risky to rely on this.
If any preflight occurs on the request needing to transmit the shared cookie, then the preflight response will very probably have to include the Access-Control-Allow-Credentials header too.
#Additional consideration
CORS spec recommends avoiding browser based automatic credentials forwarding mechanisms.
Given the difficulty of avoiding such vulnerabilities in multi-origin interactions it is recommended that, instead of using user credentials automatically attached to the request by the user agent, security tokens which specify the particular capabilities and resources authorized be passed as part of the explicit content of a request. OAuth again provides an example of such a pattern.
It would probably be more robust to follow this recommendation.
