Request token error but only in official Twitter iOS client's web browser window


#1

When a user shares a link to our application, we expect often people will use official clients to click on that link. Our OAuth problem is that we can not complete an authentication flow in the Twitter iOS client but we can in any other web browser.

When a user clicks on this link in the Twitter client, that application opens a web browser window within the app (as opposed to Safari), and the user will be sent to our site in that browser.

It is unlikely that many users will be authenticated into our site, and we require Facebook or Twitter login, so we prompt for a login. Obviously the user is most likely in this scenario to hit “Twitter”, and may be prompted to sign into Twitter if that browser has not previously been logged into Twitter itself (to be clear, this is Twitter’s authentication page rendered by api.twitter.com before prompting for authorisation, appearing in a web browser inside the iOS Twitter client).

On accepting a valid username/password, the api constantly returns the missing request token message as below:

At this point we obviously thought “we’ve made an error” and started to check our back-end code. The URLs are being created with the twitter_oauth Ruby gem, our app is running on Heroku, and so we were confident it wasn’t clock drift or implementation error on our part.

Even weirder, this flow works 100% of the time in any other browser. Safari on iOS, Safari on desktop, Chrome on desktop, you name it.

The only time we have seen it fail in development/testing is in the Twitter iOS client browser. That suggests the URLs are fine, and that we’re doing all the right things (we use SSL, etc.)

Our application which we render in the browser is an AngularJS SPA which uses some custom authorisation headers and will exploit browser local storage if available - the only thing we can think of at the moment is we’re causing a conflict somewhere.

Thanks in advance for any help.


Can't login from TV (webkit based browser)
#2

Hi @p7r, a couple of us are having the same exact issue. See thread at the following link. When did you first start noticing this?


#3

As I posted here I’m having a similar problem.

Quoted text from the other topic:

Hi I’m getting the same error from an in-app web browser on Windows Phone 8.

On monday everything worked fine so I did a beta test release. On thursday the app got tested by the testing team and it had already stopped working.

It also changed the UI.

The strange thing is that if I fetch the URL that takes me to the PIN page and paste it on a desktop browser I get to see the PIN, not the same on the mobile app.

Any official word?


#4

Prior to April 6th, 2015, OAuth would remain entirely in Twitter’s UIWebView. After April 6th, OAuth would begin in UIWebView and context switch to Safari. Request and access tokens are likely stored as session variables on Twitter’s servers. When you context switch from one web client to another, a new session is started. The tokens do not carry over to Safari.

This may be happening because the UIWebViewDelegate is doing something like this:

- (BOOL)webView:(UIWebView *)webView
 shouldStartLoadWithRequest:(NSURLRequest *)request
  navigationType:(UIWebViewNavigationType)navigationType {
  
  if (someBadCodeConditionBecameTrueForTheSecondStepInOAuth) {
    [[UIApplication sharedApplication] openURL:request.URL];
    return NO;
  }

  return YES;
}

I’m just pointing out the cause of the problem. You won’t be able to write extra code to fix it. The problem is on Twitter’s side.


#5

@thunderclap_dc - we had a similar issue last week and one of our engineers was fixing it over the weekend. He was confident it was working and then by Tuesday the above error was appearing. It seems like we had did fix our bug, but then Twitter was breaking in this flow here.

We’ve tested a few other apps and seen this happen elsewhere (e.g. Meerkat, which might be why Twitter has done this perhaps? Slow them down?), but it’s good to know we haven’t gone crazy or suddenly become incompetent.

I’m going to investigate other auth flows to see if we can get around this, but it seems like Twitter could fix this quite quickly by going back to previous behaviour.


#6

We rolled out some fixes late yesterday that should have resolved this issue. Are you all still seeing a problem here?


#7

Hi @andypiper, I’m still seeing the problem and it’s stopping us from publishing an App to the store.


#8

Has there been a resolution to this? We’re developing an app that experiences this same issue when the Twitter iOS app is installed. Any update to this would be welcomed.


#9

Did you get a resolution on this issue? We’re facing the same thing 5 months later. Any insight, if you have any, would be helpful.


#10

Hi! I didn’t get an official resolution but I found a turnaround to the issue.
The soultion is something like this (always browsing on an in-app web view):
1 - Browse to /oauth/request_token
2 - With the retrieved request_token build the /oauth/authorize URL
3 - If everything turns out ok the page will redirect to the callback URL configured on the apps dashboard (Twitter side).
4 - The web view has a navigation handlers that runs everytime it browse to another URL. There we check if the callback URL is contained in the browsing URL.
5 - If it is contained then you have to parse that URL to extract the oauth_token and the oauth_verifier.
6 - Then you have all the stuff you need to call /oauth/access_token

Hope this helps :smile:

Edit: @PixoChu