'Sign Up' via OAuth Authenticate on Mobile does not return to my application

#1

When I send desktop users to authenticate with twitter, if they click ‘Sign Up’ for Twitter, they are sent to the registration form, and then returned to the ‘authenticate’ step which prompts them to approve access to my app.

When I send mobile users to authenticate with twitter, if they click ‘Sign Up’ for Twitter, they are sent to the mobile registration form, and then they are sent to mobile.twitter.com’s home.

I need them to be returned to the authenticate step, as afterwards I redirect them to my application to ask them for further information.

Is this intentional? I vaguely remember this working differently earlier this summer.

#2

I don’t see that behavior on the iPhone simulator. Are you sure you’re passing an oauth_callback parameter when fetching a request token?

#3

what should I be doing? i have a callback URL set in my twitter application, and the ‘authenticate’ flow properly redirects back to my application’s callback URL.

my application redirects the webView to https://api.twitter.com/oauth/authenticate?oauth_token=token

the ‘sign up’ link on that page is sending the webView to https://twitter.com/signup?context=oauth&oauth_token=token

#4

I am also facing the same problem. When I try to authenticate the user in desktop site it return users to callback URL. But when I try the same in mobile browser then it does not return to my application properly. Is there any way to resolve this.

#5

You should always send an explicit oauth_callback parameter on the oauth/request_token step, no matter what you’ve provided as a placeholder with your application record. Are you doing that now?

#6

Hi guys,

Sorry to resurrect an old post but I’m having the same woes.

In a web browser a new user to Twitter can sign up to Twitter and goes back to the page with the “Authorize” button presented to them.

In a UIWebView the new user is sent to the mobile.twitter.com sign-up page… but is then sent through the rest of the signup (add followers) workflow ending on the mobile website.

There’s no way for the user to get back to authorise the app.

Exactly the same request is being made to Twitter in the two use-cases ( including the correct/same callback on the request_token step )…

Could somebody help?

#7

Incidentally… if we close the UIWebView and re-attempt the user lands on the not-signed-in oath login page… but clicking the “Sign Up” link again takes you to mobile.twitter.com, all signed-in and authenticated?

Is it normal that I can be not-signed in on api.twitter.com but signed in on mobile.twitter.com at the same time?

Also, if it’s useful… the mobile signup page does have the context, seemingly:

https://mobile.twitter.com/signup?context=oauth&oauth_token=ABC123

Thanks!

#8

This is something that should eventually be resolved but likely won’t be in the immediate future. mobile.twitter.com is really a separate application than twitter.com (while the OAuth UIs presented in api.twitter.com are really part of twitter.com). Long term, we have efforts to unite some of these auth layers and experiences between applications, but there are enough dependent tasks that’ll it’ll be sometime before you see an issue like this resolved.

#9

Thanks for getting back to me @episod - we’ll keep an eye out for a fix/unification further down the line.

#10

5 years later this still does not seem to be resolved?

On desktop, I open a popup, inform the user we’re going to a third party, redirect to twitter’s auth flow, eventually get to the end of the process, store credentials, close the dialog.

On android, I open a popup, inform the user we’re going to a third party, the user is then redirected to the android twitter app, they complete the auth flow, then they get stuck in a chromeless web view no address bar, no way to communicate back to the opener or close the pop up?

#11

However, if I UNINSTALL the android twitter app, the whole flow works flawlessly?

#12

Upon further review… the oauth library I am using was directing to twitter.com instead of api.twitter.com. Changing that url prevents the twitter app from intercepting the request.