Abraham, thanks for a quick reply... I see what you are saying...
Here is my follow up question - if my user have been previously authenticated, and I now have the access token and secret, why would I use the "authenticate" call vs. just using the "view credentials" call? In other words, by using "view credentials" I am just making sure that the access token is still valid, and I am effectively accomplishing the same thing. All in all, I agree with Chris - ideally, access and authentication should be very distinct. Twitter Oauth is still a step in the right direction vs. basic HTTP auth, but would be nice to have a strictly authentication-based call that wouldn't require user to grant the consumer any kind of access to personal data. It would be nice to have someone from the team to weigh in here to understand their rationale for this kind of implementation of authentication - is it an issue of resource constraints or is it something else? Cheers On Aug 10, 12:48 am, Abraham Williams <4bra...@gmail.com> wrote: > The difference between authenticate and authorize is that if the user is > already logged into Twitter and previously approved your application when > hitting the authenticate URL they will bounce directly back to your > application without seeing the allow prompt or any page from Twitter. With > authorize they will always see the allow prompt. > > As for privileges. Those are controlled with the access (read) and > access/update (read/write) that set your application for or pass to Twitter > when getting request tokens. They act the same no matter which method you > use. > > Abraham > > 2009/8/9 Chris Babcock <cbabc...@kolonelpanic.org> > > > > > > > > > > I looked through the API, the online discussion, and wrote test code > > > to check both the authorize and authenticate methods. I have not been > > > able to find any difference between the two, apart from the request > > > URL (and, perhaps, some differences in language between Twitter's > > > authorize and authenticate pages). > > > > Are there any differences - or have the two URLs been implemented to > > > logically separate standard Oauth from "Sign in with Twitter", but are > > > otherwise identical? > > > > The reason I am asking is because I expected "authentication" to be > > > just that - with no rights or privileges to read or write to user's > > > Twitter account. It appears that when I use "sign in with Twitter", I > > > effectively gain the same level of privileges as I do via the standard > > > Oauth authorize flow. > > > This was contrary to my expectations also, but it's in the OAuth specs, > > "OAuth authentication is the process in which Users grant access to > > their Protected Resources without sharing their credentials with the > > Consumer." -http://oauth.net/core/1.0/#anchor9 > > > I'm somewhat disappointed. "Access" is the definition of authorization, > > not authentication. I would like to be able to differentiate between > > "prove who you are" and "give me the means to impersonate you." > > > Chris Babcock > > -- > Abraham Williams | Community Evangelist |http://web608.org > Hacker |http://abrah.am|http://twitter.com/abraham > Project |http://fireeagle.labs.poseurtech.com > This email is: [ ] blogable [x] ask first [ ] private.- Hide quoted text - > > - Show quoted text -
