#12

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

3 Likes
#13

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.

#14

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

#15

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.

#16

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.

#17

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): Log in with Twitter | Docs | Twitter Developer Platform

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.

2 Likes
#18

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?

1 Like
#19

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.

#20

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.

1 Like
#21

well yeah thanks for that change, NOT.

it’s honestly annoying especially when users get to see the permission stuff again, as some said users definitely misinterpret this and the users may drop.

also WHY was this change made in the first place?

if they are always asking for permission you could also abolish this honestly ridiculous sign in flow (I need about 3 times the code to sign in with twitter compared to google whatever because we not only need to Access THREE endpoints (get a redirect URL, get a token and THEN finally get the credentials) and do quite a signature rundown on all of them,

and instead just use a generic redirect url and exchange the code for just the account data, after all the authenticate endpoint is just for signing in with twitter, not doing weird stuff with the account.

compare with google. there’s a static redirect URL and when I get the code I only need to access one endpoint which gives me a token (which I just drop because I dont need it) and most importantly a JWT of the account data, so the biggest part of the signin code is to verify the JWT properly instead of building these ridiculous connections up and down to twitter.

I mean signatures are nice and secure, I give you that much but combining a ridiculously large server-side flow with the user being asked over and over again is not pretty.

also by the way, the docs are still not updated.

also the suggested alternative of just using verify account if you already have it is not helping because the point of signing in to twitter is that you dont know what twitter to talk about and you cant verify that the client is signed in, also you need the token,

Social Sign in usually results for me in this flow:

  • user is on login page and clicks sign in with twitter
  • user gets to provider (which checks the login) and if he hasnt done so previously he agrees to the sign in, if he already did, they just redirect back
  • I get the code
  • I exchange the code for the token and then the user data (or on some providers I just get the user data along with the token)
  • I drop the token, because I only need it for sign in.

I would say because the authenticate endpoint is just for Twitter signin anyway I would make at worst the following restrictions:

  • no tokens to act on behalf of the user, just a one-time thing to check the twitter account the user has used
  • no permissions except for basic account data
  • (for more privacy of the user) use application specific opaque oauth userIDs, without transmitting screen name, email or anything, meaing there is nothing the application has to cross-track the user in anyway, and the application that just wants to sign in doesnt need to know which specific account accesses it, just whether it’s the same as what is used for a given user already

the last point would obviously mean that users would need connect with twitter again, but aside from that it’s a nice measure to prevent services from trying to track too much, which in the end would be good because it helps privacy.

#22

I rather wonder how you plan to implement this. after all with the token you cannot check whether the browser is signed in, and you need to know which acc you are talking about, 2 things which were definitely not needed before because twitter does those normally (it returns a token that is fresh and can be used to check the account and then drop it).

technically you would only need the token for longer if you need to ACT for the user (e.g. do posts)

this has nothing to do with javascript, just that twitter waits a while and displays a page before redirecting.

FB login works perfectly fine and quick without javascript and that’s how it should be.

#23

Hello Andy,

I’ve taken some time to review the public documentation for the /account/verify_credentials API endpoint and must concur with other concerned developers that this does not address the workflow our product uses the /oauth/authenticate endpoint.

As many others have expressed we are using the /oauth/authenticate endpoint to perform authentication of users of our system. Because they are unauthenticated when they visit us, even if we stored an oauth token from a previous successful authentication, we don’t know which users stored oauth token to verify in /account/verify_credentials.

As @Connexinet, @My1, and others have highlighted your suggestion is not relevant to the Sign In With Twitter workflow. Unfortunately some of our customers who also think the current interstitial page is less than ideal found your announcement. I’ve gotten messages from them asking why I have not updated our codebase to work with your proposed work around. Attempts to explain things to them are met by challenges suggesting I just don’t understand the twitter API, since a twitter staff person clearly explained what to do. Am I missing something here?

If not - in this interests of providing clarity - can you update either this thread or the announcement thread with a confirmation that /account/verify_credentials will not be a useful replacement for oauth/authenticate for social sign in workflows?

#24

actually hilariously enough using verify credentials is PART of the oauth flow.

what you probably meant is using verify credentials on an old token, and yes that surely is definitely a bad Idea for signing in.

#25

Good to see that social influencers aren’t the only type of people Twitter enjoys disappointing lately.

In all seriousness, this change does nothing to improve security of Twitter or their user accounts, and simply puts more hassle and risk into existing applications by using hacky and insecure solutions like @andypiper mentioned in their post.

#26

I’m uncertain as to how this post adds to the value of this thread.

We have explained the background to this change and acknowledge the disappointment and frustration it causes.

Are you able to provide any more constructive feedback?

#28

Unless you are on the Twitter security team, this is not a statement you can makes in good faith.

1 Like
#29

well in general it does add a lot more confusion to the Users which in itself is bad for the security and UX.

because there are only 2 things that can happen:

  1. the user gets insensitive to these prompts and always clicks through (and possibly overlooks a permission upgrade → bad for security
  2. users get confused, perhaps misunderstand stuff and possibly leave the service as result → bad for the service as a whole.

so in the end users are either getting deaf to those prompts (which already happened big time with things like the UAC in windows, where users just click through or flat-out disable the thing completely without even understanding why it’s there.

sure it may technically be more secure to have each sign in request approved but at least the site should show that properly and especially tell the user that this is now happening everytime.

and also highlight that no new permissions are wanted.

#30

If it is a breaking security issue it probably would not have lasted this long, but if it did, then there should be a better explanation than “it keeps users more informed of the permissions they grant,” because as @My1 points out, it turns into agreeing to the iTunes terms and conditions. I’ll be happy to eat my words if there is some other explanation that hasn’t been shared with us, even if I cant see one.

#31

what is so special about the iTunes ToC? not that I read most of any ToS anyway in the first place, but are those from itunes special in any way?

the most hilarious ToS I remember was amazon.
this is actually hilarious some guys actually got someone to read out those:

#32

This thread is heading off-topic.

We’ve explained that a change was made to this flow, and provided a reason. We’ve apologised for the confusion and difficulty this has caused. The communication and notice of the change should have been better in this case.

We are aware that this is causing frustration to some of you, and to users of your apps. We’re looking in to ways to mitigate these issues, to clarify the documentation, and to improve the sign in process and dialogs for the future. I’d agree with @My1 that there is a danger of users becoming blind to these prompts so it would be good to improve this situation. I cannot make any commitment as to when these updates may be completed, as there are many different threads of work underway internally.

Closing out this thread to avoid further “me too” responses. If you have a different technical question regarding implementation of Twitter OAuth or sign-in please open a new topic in this category.

2 Likes