Twitter App permission not honored on subsequent oauth/authenticate calls



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.


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.


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?


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.


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.


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?


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


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.


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.


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:


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.