Update: Twitter has removed oauth_bridge_code support from the API
At @appworkshop in July @themattharris pre announced @Anywhere oauth_bridge_code support. The official announcement has yet to appear but this blog post provides everything you need to get started.
An @Anywhere oauth_bridge_code can be used to get a long lived OAuth 1.0a access_token for the REST API. This allows sites to use @Anywhere and the REST API while only requiring users to only use one authentication method.
The basics are that after a users completes the sign in process for @Anywhere the browser gets an oauth_bridge_code. This oauth_bridge_code can be passed to the /oauth/access_token API endpoint signed with your applications consumer key and secret. If everything checks out Twitter will return a standard access_token for the REST API.
Now lets see some code!
Lets start with authenticating the user using the direct link method described in Hacking Twitter OAuth. You will need to change the oauth_client_identifier to you applications OAuth 1.0a consumer key (AKA your @Anywhere API key) and oauth_callback_url to a URL authorized for the application.
Redirect the user to that URL will be prompt them to connect with your application before being redirected to the oauth_callback_url. Attached in the oauth_callback_url fragment will be an oauth_access_token and am oauth_bridge_code.
Now make a signed POST request to https://api.twitter.com/oauth/access_token using your applications consumer key and secret.
Awesome! You now have a OAuth 1.0a access_token as if you had used the standard OAuth flow with the @twitterapi.
Lets look at getting the oauth_bridge_code using @Anywhere's connect button. This code is a simple HTML document that displays an @Anywhere connect button and handles authComplete on the users return. The oauthComplete uses @jQuery to post the oauth_bridge_code to convert.php which does the same conversion we already saw.
Catch the POST and convert the oauth_bridge_token to an access_token as described above.
An alternative method to verify @Anywhere users, instead of calling verify_credentials with their access_token, is to compare the sha1 hash of their user_id concatenated with the consumer_secret with the value of the twitter_anywhere_identity cookie.
You can read the source information on the slides @themattharris put together for @appworkshop. Skip to page 51.
At @appworkshop in July @themattharris pre announced @Anywhere oauth_bridge_code support. The official announcement has yet to appear but this blog post provides everything you need to get started.
An @Anywhere oauth_bridge_code can be used to get a long lived OAuth 1.0a access_token for the REST API. This allows sites to use @Anywhere and the REST API while only requiring users to only use one authentication method.
The basics are that after a users completes the sign in process for @Anywhere the browser gets an oauth_bridge_code. This oauth_bridge_code can be passed to the /oauth/access_token API endpoint signed with your applications consumer key and secret. If everything checks out Twitter will return a standard access_token for the REST API.
Now lets see some code!
Lets start with authenticating the user using the direct link method described in Hacking Twitter OAuth. You will need to change the oauth_client_identifier to you applications OAuth 1.0a consumer key (AKA your @Anywhere API key) and oauth_callback_url to a URL authorized for the application.
Redirect the user to that URL will be prompt them to connect with your application before being redirected to the oauth_callback_url. Attached in the oauth_callback_url fragment will be an oauth_access_token and am oauth_bridge_code.
Now make a signed POST request to https://api.twitter.com/oauth/access_token using your applications consumer key and secret.
Awesome! You now have a OAuth 1.0a access_token as if you had used the standard OAuth flow with the @twitterapi.
Lets look at getting the oauth_bridge_code using @Anywhere's connect button. This code is a simple HTML document that displays an @Anywhere connect button and handles authComplete on the users return. The oauthComplete uses @jQuery to post the oauth_bridge_code to convert.php which does the same conversion we already saw.
Catch the POST and convert the oauth_bridge_token to an access_token as described above.
An alternative method to verify @Anywhere users, instead of calling verify_credentials with their access_token, is to compare the sha1 hash of their user_id concatenated with the consumer_secret with the value of the twitter_anywhere_identity cookie.
You can read the source information on the slides @themattharris put together for @appworkshop. Skip to page 51.
Is it possible to go the other way?
ReplyDeletee.g. Use the standard OAuth flow to generate a 1.0a access token, and then somehow obtain a @Anywhere token also.
@Anonymous: No
ReplyDeletelame.
ReplyDeleteAnonymous: If you can go one way there really isn't any need to go the other way.
ReplyDeleteThank you SO much for this, but question: I can't seem to capture the oauth_bridge_token when using the authComplete listener (for a .signIn() method used on a generic login button.)
ReplyDeleteDoes this not work unless you use Twitter's .connectButton?
Not needed, but in my case it would be quite helpful: I do not intend to use the @anywhere connect button, and I already have OAuth 1.0a working. Now I want to use T.isConnected() feature from @anywhere, but I have to completely change the verification process in order to do so.
ReplyDeleteI am to the point where I retrieve the access token using the oauth_bridge_token, but I keep getting 401s.. I will get eventually, but it would be easier if it I could go the other way.
Correct me if I am wrong but - Even after converting the bridge token into a long-term oauth 1.0a token, then verifying and storing the auth token and secret - there are still only a few hours where the @anywhere script recognizes the logged in user. if the user comes back the next day, you have to go through the motions all over..
ReplyDeletemuch different and less useful than facebook connect - where the logged in user is connected to an app automatically after the first time they authorize it.. that is what makes it suitable for use as authentication. essentially T.isConnected() should return true if the user is logged in to twitter, and has previously authorized the app.
I noticed - there does not seem to be an "authenticate" endpoint for the oauth 2, only "authorize".. the 1.0a implementation has both endpoints, and I always used authenticate, not sure if that is my issue.
not to mention my custom authComplete callback function is getting called multiple times (between 1-3) and obviously it fails after the first attempt, since it has already exchanged the token.
ReplyDeleteAnonymous: If you already have the standard Sign in with Twitter flow implemented that switching would be more work. You don't have to use the @anywhere connect button. You could just use a link or even the existing Sign in with Twitter button.
ReplyDeleteYes @anywhere tokens are short lived. About 3 hours.
EvilJordan: Not sure. I've never tried it with the signIn() method. I would think that it should work though.
ReplyDelete@abraham Yes, I formulate my own auth link, I am not using the connect button.
ReplyDeleteThe problem comes when I use an ouath 1.0a link. there is no way to make @anywhere honor the returned token.
however, even when getting the @anywhere token / bridge, the @anywhere portion is only good for a few hours, so its not worth the bother.
is there anything closer to facebook connect in the twiiter api?
Anonymous: @anywhere is as close to Facebook Connect as you will get from Twitter.
ReplyDelete@anywhere tokens only last a short period because if someone gains access to them they allow access to all of the users data. There is no secret hidden in a server somewhere to help protect the user longterm.
when a user who is logged into twitter and has authorized my app returns to my @anywhere page -
ReplyDeletetwitter should be checking twitter.com cookies on the back-end (iframe etc.), and executing a callback on my page to let me know the current user is logged in and auth-ed. there should be no interaction needed with any ui, it should be part of loading the anywhere script.
that flow is unrelated to an anywhere token. it only requires the bridge - or better just a regular oauth token / verifier..
with no secret and expiring the token so quickly, it just doesn't seem like real security. fine by me, i prefer rest apis over client apis anyway.
i would hope that the anywhere token is only good for requests made with a particular request signature - 1. domain, 2. public key, 3. token, etc.
but even then, twitter would need to take care when passing data (particularly domain name) between the anywhere js functions on the page and the iframes that do the actual back-end work. there are straightforward ways to trick this process without proper precautions.
Thank you SO much for this, but question: I can't seem to capture the oauth_bridge_token when using the authComplete listener (for a .signIn() method used on a generic login button.)
ReplyDeleteDoes this not work unless you use Twitter's .connectButton?
Anonymous: If you can go one way there really isn't any need to go the other way.
ReplyDeleteIt looks like Twitter stopped accepting bridge codes:
ReplyDeletehttp://groups.google.com/group/twitter-development-talk/browse_thread/thread/50fcc4f28cd6b659/
I think they should rename @Anywhere to @Nowhere, how difficult could it be to work the same way FB.api does?
ReplyDeleteTwitter Documentation :Poor
Twitter ObjectModel :Poor
Twitter OAuth Implementation:Poorest
The only thing I'd hope from Twitter is an 'override', extra param or whatever to which I can pass an OAuthToken so I can sign in with a know token, without having to make my user travel around the web with his credentials, from IFrame to IFrame.