The current Add-In platform for the Office family (Outlook Web, Office365 Web and Offline clients) are essentially websites loaded into an iFrame with some Office JavaScript libraries to provide interoperability to the host platform. The neat thing is this works across all client types (including iOS and Android) and uses general web technologies, e.g. React.
TL/DR: I had to set SameSite options to None in order for cookies from my add-in that the server set on a POST request, where actually sent back to the server on subsequent requests. In ASP.NET you do this in your Startup file as follows:
services.AddCookie(options => { options.Cookie.SameSite = SameSiteMode.None; });
// Or if you're using AddIdentity, you set it like this:
services.ConfigureApplicationCookie(options => { options.Cookie.SameSite = SameSiteMode.None; });
ASP.NET Core Identity and Same-Site
ASP.NET Core Identity set the same-site setting for the Auth cookie to Lax. What does this mean? We let’s consult this handy table by Sjoerd Langkemper:
Essentially the lax setting prevents a class of CSRF attacks that are based on the user being logged-in somewhere and the attacker using cross-site POSTs or iFrame to communicate with the server in an authenticated fashion. The authentication cookie simply is not sent.
Office365 Add-Ins authenticating via POST AJAX requests
In theory this is a great default level of security but it does break a lot of workflows (e.g. see here for breaking changes to the auth flow in iOS).
In my case my Add-In was authenticating to the API via a AJAX POST request from an iFrame. This is forbidden with same-site set to lax.
Setting same-site to None as demonstrated above returns the functionality to the default for browsers and enables the add-in to authenticate and the authentication cookie is sent with subsequent requests.
Consequences of Same-Site None
Whenever you change ANY security setting you should be aware of what doors you’re opening and this is even more true for the default settings on your authentication mechanism. Having spent almost a decade working with security researchers I’m not happy at all having to disable a security feature, but due to the architecture of Office365 plugins using iFrame I have to (if you’re reading this and find a different way, please share).
So by enabling my use-case how can I mitigate other holes I’ve opened?
- POST requests should have CSRF protection, just the way we’ve done it in the past.
- GET requests (and POST too really) should be safe in theory, but if you’re activating CORS capability then you should take special considerations.
- And make sure you’ve got http only activated for authentication tokens.
See also: