Correlation Cookie not found when user click link from Office application

[jesong]

If you have a link in microsoft office(Excel, Powerpoint, Word), and the target linked used OpenIdConnect with automatic challenge. When you ctrl+click on the link in office application, You'll see following error from server log:

2017-06-08 07:51:21.307 +00:00 [Information] HttpContext.User merged via AutomaticAuthentication from authenticationScheme: "Cookies".
2017-06-08 07:51:21.932 +00:00 [Warning] '".AspNetCore.Correlation.OpenIdConnect.mVRDSZb8AZUAlSv_hIBeK3Uri5cJHtu4fNDv1skOTYE"' cookie not found.
2017-06-08 07:51:21.932 +00:00 [Information] Error from RemoteAuthentication: "Correlation failed.".

This is because the cookie is generated with the 302 redirection from challenge action. But office has following issue that caused the cookie missing in browser:

https://support.microsoft.com/en-us/help/899927/you-are-redirected-to-a-logon-page-or-an-error-page-or-you-are-prompted-for-authentication-information-when-you-click-a-hyperlink-to-a-sso-web-site-in-an-office-document
https://stackoverflow.com/questions/2653626/why-are-cookies-unrecognized-when-a-link-is-clicked-from-an-external-source-i-e

[Eilon]

Hmm, this is indeed a very unfortunate situation. I think many users of Office have seen this behavior once or twice. Unfortunately, it's not clear to me what would be an effective strategy to mitigate this from within ASP.NET Core. The suggestions on the Stack Overflow post seem to be "workarounds" and might not be completely reliable.

[jesong]

Is there a way just omit correlation cookies? It's for security?
That's true we can have work around like

1. We can check the user agent if it's from office we give empty 200 response. This will cheat office to open the page in browser directly and the following 302 will happen in browser
2. We can create a login page that returns in 200 and redirect to real signin api with 302 in javascript

But, as u can see, all these are not so prefect.

[Eilon]

Yeah I am very suspicious of checking for user agents - that's kind of the number one no-no in building apps...

[Eilon]

Closing this because the correct fix is ultimately in Office where it needs to do the correct redirect if its initial request fails. Working around this in ASP.NET Core would just lead to other bugs.

[smichtch]

...checking for user agents - that's kind of the number one no-no in building apps...

@Eilon, I think number one no-no should be breaking apps?

But I totally agree that Office needs to fix these pre-fetch requests (which are either too clever or not clever enough, probably the former) to work with OAuth and single-signon workflows in general as those become more ubiquitous.

That said, why can't ASP.NET Core have a generic option to inject a client-side redirect to the login page like suggested here: https://support.microsoft.com/en-us/help/899927/you-are-redirected-to-a-logon-page-or-an-error-page-or-you-are-prompted-for-authentication-information-when-you-click-a-hyperlink-to-a-sso-web-site-in-an-office-document

For an HTTP request that may be a multiple-session client request, issue a client-side redirect response instead of a server-side redirect response. For example, send an HTTP script or a META REFRESH tag instead of an HTTP 302 response. This change forces the client back into the default Web browser of the user. Therefore, the default browser session can handle the call and can keep the call in a single, read-only session.