search

aspnet-contrib / AspNet.Security.OAuth.Providers

OAuth 2.0 social authentication providers for ASP.NET Core
Apache License 2.0
2.38k stars 538 forks source link

X/Twitter v2 iPhone Browser Interception Issue: Correlation failed. #811

Closed Mike-E-angelo closed 12 months ago

Mike-E-angelo commented 12 months ago

Describe the bug

I have been tracking down an issue experienced with the Twitter v2 authentication workflow when using the iPhone and the Twitter native iOS application is installed. This appears to be an ugly issue and very complex. I have had several users report this and have had two members in particular work with me over the past several days to isolate what is going on.

It has ended up being so complex that I purchased a LambdaTest Real Device plan so that I can reproduce this for myself (no, I am not a fan of Apple and do not own any of its products 😅).

After a day of configuration and wrestling with the device and applications, I believe I have figured out what is going on, and will attempt to explain the issue below.

To start, the iOS Twitter/X native application must be installed on the user's device to see this issue. When the oauth authorize endpoint is requested by a Safari instance, the Twitter/X application appears to be intercepting this request and opening its own instance of Safari in its application process, and is completely separate from the device's Safari. The result is two separate Safari instances:

  1. The device Safari instance that starts the workflow where the correlation cookie is set
  2. The Twitter app Safari instance where the workflow is finished -- and a correlation cookie is not set, leading to an exception.

Steps To reproduce

  1. Open the device Safari instance
  2. Visit an address that has a Twitter sign-in button, press it, and begin the ASP.NET Core sign-in workflow. This sets the correlation cookie on the device Safari instance. image
  3. The ASP.NET ouath workflow continues and sends the browser to the authorize endpoint.
  4. iOS Twitter Application detects this authorize endpoint request and intercepts it, opening it in its own Safari instance (note the all-too-subtle Safari icon below to open in the device's Safari instance): image
  5. Press Authorize App
  6. This completes the oauth process on Twitter/X's authorize endpoint and then sends the request back to the ASP.NET application (/signin-twitter endpoint), but it's now in a different Safari instance than the one that initiated it. The correlation cookie is therefore not there and throws an exception. 💥

Expected behaviour

It would be ideal to share the correlation cookie across browser instances (or force Twitter/X to use the initiating browser instance), but I am not sure if this is possible.

Actual behaviour

When initiating the Twitter v2 authentication workflow in a Safari instance and the Twitter iOS application is installed, the Twitter's Safari instance is used to intercept the request, which is a different Safari instance that was used to initiate it. This results in a Correlation failed exception as the correlation cookie is on another Safari instance (the one that initiated the workflow).

System information

Additional context

This is really incredibly complicated and has been reported for weeks, finally tracking it down today. I have done my best to relay this issue but additional questions may remain. I will do my best to clarify any further uncertainty around this issue for you.

kevinchalet commented 12 months ago

While I appreciated the amount of details you shared, there's sadly nothing at all that we can do on our side: the aspnet-contrib provider is purely a server-side component and cannot control how cookies are handled by the browser.

I'm afraid you'll have to ask Musk and its minions to take a look at this issue 😄

kevinchalet commented 12 months ago

And FWIW, I personally do own an iPhone, so I made the test using your website: the Twitter "web view" doesn’t even load properly. All I get is a black screen 🤣

image

Mike-E-angelo commented 12 months ago

I'm afraid you'll have to ask Musk and its minions to take a look at this issue 😄

Fair enough. 😊 I was hoping that there may be an "add the DisableNative flag to fix this" or some equivalent, but this appears to be wishful thinking. If anything, I am hoping that this will help others who may be running into the same issue. I have been encountering Correlation failed messages for months but thought they may be due to upgrading from Twitter's Oauth v1. When they persisted after a few weeks, I knew there was something going on here different from that.

All I get is a black screen

Indeed, I have noticed all sorts of problems today myself while trying to figure out what is going on. This occurred several times:

😭

Thank you for the bad news. Closing for now.

Mike-E-angelo commented 12 months ago

Here goes nothing 😬🤞 https://twittercommunity.com/t/iphone-twitter-application-intercepts-safari-authentication-leading-to-invalid-state/206890

kevinchalet commented 12 months ago

As a workaround, you could offer a native app to your users, but it's definitely not a cheap option 😅

Mike-E-angelo commented 12 months ago

Indeed @kevinchalet it would be expensive to both myself in terms of code + managing the different store deployments (+ funny content policies I've heard so much about), and also in terms of application users as they would be paying the store tax I would no doubt pass along to them. 💰

Mike-E-angelo commented 12 months ago

FWIW I have created a bit of a solution (read: hack) to address this, where if the Correlation Failed error occurs I basically restart the authentication workflow process instead of throwing/showing an error. The user has to press the Authorize app button twice, but that's... ok? 🤔 Better than the alternative.

https://github.com/DragonSpark/Framework/blob/6e692b50dab9173af074846883c233e8f0015e12/DragonSpark.Application/Security/Identity/Authentication/DeviceInterceptionAwareRemoteFailure.cs