Twitter App permission not honored on subsequent oauth/authenticate calls

[n8whnp]

The first time a new user uses our app to authenticate, they are asked to authorize the app to use basic information. If you authorize it and then go back to Twitter -> Settings & Privacy -> Apps you will see the App listed as active. However if you logout of my application and make a second oauth/authenticate to re-login. Instead of redirecting you back to the callback URL, you are asked to authorize the application again. Is this a bug on your side? The behavior started occurring friday the 29th.

[AllRugbyCom]

Hi,

I have exactly the same problem here and it started to happen at the same date, last friday, it’s very annoying… Since then I keep trying to find why suddenly we have to re-authorize the app even if we did once before.

Our code didn’t change, we always use the autenticate url and we have checked the box to “sign-in with twitter” in app settings…

Thanks,

[Tony_Kennah]

OK - So this is another report identical to one I’ve just posted. So “they” have definitely changed something!

Authentication again and again

I have 2 apps. One is using authenticate http://pluckier.ddns.net and the other authorize www.pluckier.co.uk - or in twitter4j getAuthorizationURL() & getAuthenticationURL() yet both force me to click the authorize button before redirecting to my app, regardless of if you’ve already authorised the app or not. In twitter app management both apps settings are set as authorize and both have allow twitter signin. I’ve read about this issue on other posts and looked at the API to see the difference…

[andypiper]

I’m looking into this at the moment.

[Connexinet]

Hi Andy,
Any update on this? We have been having this issue for many days now.
Is this there a work around?

Thanks
Samir

[andypiper]

There is no workaround at this time. I’ll post an update as soon as I can.

[Connexinet]

ok, thanks!

[Daskew78]

Same issue on my site also, following…

[chrstffr]

Same issue. Watching thread.

[andypiper]

I’m working on a more detailed response, but in the interim, I can confirm that this behaviour has been changed so that both endpoints now operate in a similar manner. There are no current plans to revert to the previous behaviour. We apologise for any inconvenience caused.

[Connexinet]

Andy,
This has become a major problem for us (not just inconvenience), users are dropping because they think we have changed the permissions requested, and many users cancelling their account all together.
Authenticate workflow was meant to allow for logging in, not to authorize the app, sadly we now have to drop Twitter authentication to signing with the service.
Thanks,
Samir

[andypiper]

Thank you for the context, we’re continuing to work on this.

[pas256]

Hi Andy,

Any update on this? It is a really jarring experience for our growing user base to have to click so Authorize each and every time so really I hope the functionality goes back to match the documentation.

[andypiper]

Please see this announcement Recent changes to Twitter’s OAuth login flow and API endpoints

[n8whnp]

Andy,

Thanks for the update, we will take a look at storing the authorization token and using validate credentials. I’m not convinced at this point that it is an adequate replacement for our current use case.

Going forward I would ask you to consider refining the interstitial screen which is shown when an user who has already authorized the application is asked to confirm they want to continue to authorize it. Right now a user can see the app as authorized for their user in the Settings & Privacy -> Apps section and is confused. We get users who think clearly we are not calling the API correctly or that we have changed the required permissions when neither of those is the case. Providing a clearer message that you are asking them to confirm they want to continue to authorize the application to use their account would reduce the confusion.

[andypiper]

That’s a good idea, and I’ll certainly pass it along to the teams responsible. I wouldn’t be able to commit that we will be able to do that on any given timescale, though.

[Connexinet]

Well unfortunately you look at it as authorization workflow, but there are two distinct workflows:

1. Authorization (and we already handle that by storing the token)
2. Sign in with Twitter (SSO): https://dev.twitter.com/web/sign-in

The second one is currently broken, the point of it is to authenticate a user and have higher conversion (by eliminating extra login steps), but it now adds another step that ends up with much lower conversion, we are better off using our own Sign in solution.
The older workflow, although slow (since it redirects, unlike Login with Facebook which uses Javascript), reduced extra steps a user needs to take to sign in. So basically, this is no longer SSO, it is just Twitter authorization page.

[DrinkingJimmy]

Add me to the list of disappointed devs, Andy. Very few of my users have the patience or trust necessary to reauthenticate at every log in.

If you want to contextualize this for your management, imagine if Twitter users had to read and agree to Twitter’s TOS every time they logged into Twitter itself.

For now, I will just abandon Twitter as a Sign-in option, and revert to local, FB and Google.

You’d think Twitter would want free analytics about user behavior, but I guess nah?

[andypiper]

Just to reassure you that I have indeed been making these cases to the relevant teams. I’m not able to commit to what the resolution might be here, yet, but I absolutely empathise and do understand the points you’re all making, both as a developer myself and as a user of apps that have implemented our sign-in option myself.

Please be patient (even more!) while we continue to look at better ways forward here. In the meantime, I can see why you’d look at changing your approaches.

[ThomasArdal]

Another disappointed dev. It doesn’t make sense to user Twitter login for us anymore, since it’s no longer easier for our users compared to username/password login and the approval step causes confussion and extra support.