3-legged vs Twitter Sign in

[My1]

especially now that Twitter signin (via authenticate) also forces a re-allow it seems totally weird as they are now totally identical.

what was the point in the first place between differing in the redirection behavior? can 3-legged do things Twitter sign in cannot and that’s why it is needed from a security standpoint to use it?

I mean both are Identical except for the auth endpoint 3-legged is authorize and Twitter sign in is authenticate, even the docs say so.

[AlexDeCamillo]

It appears that they do identical things operations now. Unfortunately, it also appears that the update to the API was made before they were ready the update the API documentation.

[My1]

while they are identical now, I still wonder why they had to make them seperate in the first place, I mean even in classic oauth the standard flow is to let everything pass that is already known and not a permission upgrade.

[andypiper]

The background is described in this announcement. We apologize that we’ve not yet completed the documentation changes.

[My1]

@andypiper well but the last larger paragraph is absolutely junk.

using old tokens cannot be used for signing in with twitter because a) the application doesnt know WHO wants to sign in, and the application cannot check whether that person is properly signed into twitter, which are the 2 important things of twitter sign in. twitter sign in can only be used with tokens where you know that they are fresh and come from that specific client you are trying to sign in.

long story short, the small step of letting the user bounce through twitter is the SOLE THING making OAuth for social sign-in secure

but I rather wanna know why there was a need to keep authorize and authenticate seperate in the first place especially since EVERY service I played OAuth with is not gonna ask again (except for Github, which kills permissions from apps that havent been used for a long time, or steam although it doesnt have any authentication on their openID at all)

and in the other thread I also asked why it isnt possible to create a simple “Authentication only” permission which doesnt need this stupid intersitial all the time but instead grants less data (essentially just one pairwise ID which is unique to both the application and user (microsoft does that as well by the way) and it’s pretty awesome since an application can recognize you but not identify you).

and if just need this most basic permission there should imo be no more intersitials beyond the first one.

[andypiper]

Thank you for your opinions - I’d remind you to review our community guidelines that reflect the standards of discussion we expect on the developer forums.

Twitter’s OAuth system has been in place for a long time as you know - unfortunately I’m unable to speak to the original design choices as I was not personally involved in the implementation. In terms of the future plans, we’ve not yet added this to our roadmap, but we’ll take on board the ideas shared by the community. As I’ve said elsewhere, we’re looking into alternative interstitials and documentation improvements, but these things can sometimes take time to deliver.

[My1]

I was not saying anything about you, I was saying that the the paragraph about using old tokens is totally unfitting for sign in with twitter.

“But, remember to criticize ideas, not people” that’s exactly what I did.

but as I said the sign in flow is based on the fact that the user bounces through twitter and gets a fresh token.

and as others have said they are using losers because of this change.

[AlexDeCamillo]

I had a similar issue, and while it would be nice to just have the user move through the authentication, there are ways to go about solving this issue.

The approach I am using, is keeping the global session variable intact and using it to store the tokens. I unset this variable when the user would logout of my application. This approach would require a user to reauthorize on each new session, but in the current session could go through as many times as needed.

You could also use a database to store tokens and when a user signs in, you could retrieve the tokens and use those. The tokens should remain valid as long as the user hasn’t revoked access to the application or your consumer tokens haven’t changed.

For my application, it is predicted that most users will use the application in a single session and will not use the twitter functionality after one time. Because of this, we have decided it okay to reauthorize on each new session. Your application needs may differ and although I have not tested it myself, I believe the database solution would solve your problem if re-authorization on new sessions would be an issue.

[My1]

for the current session I dont need the tokens as I have a session handling for that, one just needs to login using twitter to get that session, and that step has become junk with this change.

each time when the session expires, the user logs out etc. the user would need to go through twitter again which wasnt a problem before.