Sometimes we still have to support some legacy code. And provider-hosted apps in SharePoint are one of the pains we still have to maintain. Since the announcement of Microsoft to only allow TLS 1.2 connections to Office 365 starting June 2020 we started to update legacy provider-hosted apps.
https://docs.microsoft.com/en-us/office365/troubleshoot/security/prepare-tls-1.2-in-office-365
The easiest way to update legacy provider-hosted apps to use TLS 1.2 is just to update the .Net framework version to the latest version (min 4.7.2) and to make sure that the following settings in the Web.config file are correct
<compilation debug="false" targetFramework="4.7.2">
The runtime version should also be the same in the web.config
<httpRuntime targetFramework="4.7.2">
Your solution is now using TLS 1.2 and everything is good to go.
In December 2019 there was also an update on the .Net framework 4.7.2 and higher and this patch is now being released in Azure. This specifies that within iFrame’s (that provider-hosted apps are) the ASP.Net session cookie is not automatically sent with a call anymore. This is because of Google updating Chrome changing the default behavior of cookie handling in its browser. This had an impact on many Microsoft services so they had to react.
https://blog.chromium.org/2019/10/developers-get-ready-for-new.html
If your App only uses redirects then you will probably not see an impact on your app. But if you have some calls with JavaScript to get information out of your app then you will start to see an impact. This is because the session holds important information that the boilerplate code provided in a basic SharePoint Provider Hosted app needs to authenticate you towards SharePoint. (SharePointContext.cs and TokenHelper.cs classes). More information about this update can be found here:
https://docs.microsoft.com/en-us/aspnet/samesite/system-web-samesite
The bottom line is when you start experiencing issues with call’s not being authenticated anymore and you can see in your browser development tools that your ASP.Net session cookie has a “LAX” policy. Then add these additional lines to your web.config.
<appSettings>
<add key="aspnet:SuppressSameSiteNone" value="true" />
</appSettings>
<system.web>
<authentication>
<forms cookieSameSite="None" />
</authentication>
<sessionState cookieSameSite="None" />
<system.web>
Beware this is just a temporary measure but this should buy you some time to upgrade in a better way like described in the ASP.Net blogs by Microsoft
https://devblogs.microsoft.com/aspnet/upcoming-samesite-cookie-changes-in-asp-net-and-asp-net-core/
And apparently I wasn’t the only one with this problem :-)