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.
