Perhaps the type of login flow they’re getting to is that of an OIDC form_post response method? An auto-posting form is returned from the identity provider, which is then submitted to the relying party.
At least in .NET Core I observe a cookie for the OIDC nonce (.AspNetCore.OpenIdConnect.Nonce - defends against replay attacks) and a correlation cookie (.AspNetCore.OpenIdConnect.Correlation - tracks session through the redirect handshake). Both of these are created during the login redirect sequence and not intended to live beyond it.
The correlation cookie is set to SameSite=None here
https://openid.net/specs/oauth-v2-form-post-response-mode-1_...
At least in .NET Core I observe a cookie for the OIDC nonce (.AspNetCore.OpenIdConnect.Nonce - defends against replay attacks) and a correlation cookie (.AspNetCore.OpenIdConnect.Correlation - tracks session through the redirect handshake). Both of these are created during the login redirect sequence and not intended to live beyond it.
The correlation cookie is set to SameSite=None here
https://github.com/dotnet/aspnetcore/blob/master/src/Securit...
The nonce cookie is set to SameSite=None here
https://github.com/dotnet/aspnetcore/blob/master/src/Securit...
I’m not familiar with many other auth flows outside of OIDC/OAuth2 but I wouldn’t be surprised if other SSO-like flows have similar mechanisms