This post is a contribution from Westley Hall, an engineer with the SharePoint Developer Support team
If you have a SharePoint provider hosted add-in running on Azure web services, and it stops working when hosted on a SharePoint page inside a app part (or client web part/add-in), or an iframe, then likely you have hit this issue caused by a change in the default cookie property SameSite.
After the last .NET update rollout, the SameSite property value on the ASP.NET_SessionId cookie is set to Lax which prevents the cookie from being sent to an iframe if the domain of the iframe is different than the host page. In a SharePoint provider hosted web part add-in, it will always be in a different domain.
Here is an example of that session cookie-
Set-Cookie: ASP.NET_SessionId=xxxxxxxx; path=/; HttpOnly; SameSite=Lax
Normally the xxxxxxx would be a random identifier of the session.
This session usually is used in the ASP.NET application to maintain the authentication, so what ends up happening is that the frame tries to redirect back to authenticate on the second time there is a post or any ajax call to the same app instead of using the session.
Sometimes it will throw a 405 Method Not Allowed error since ajax calls can trigger a CORS OPTIONS request, and that will be rejected by SharePoint.
To resolve this, set the defaults in the web.config as follows in the system.web section-
<httpCookies sameSite="None" requireSSL="true"/>
<sessionState cookieSameSite="None" />
When SameSite is set to None it doesn't force the requirement for the iframe and host to be in the same domain.
More on the .NET update here-
Here is how to update the Web.config file on the live instance of your Azure web app-
This will bring you to the file view below-
This change should also be added to any source code projects that the web application was deployed from, for future deployments.