Chirp 2010: Too many secrets, but never enough: OAuth at Twitter

  • 10,911 views
Uploaded on

Slides from the session given by @raffi and @episod at Chirp. Additional links and slides included.

Slides from the session given by @raffi and @episod at Chirp. Additional links and slides included.

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
  • If you want to convert '.key' presentation file to '.pdf' or '.ppt' you can use online service at http://www.zamzar.com/ for this.
    Are you sure you want to
    Your message goes here
  • Read this as soon as you can.
    Are you sure you want to
    Your message goes here
  • Finally, there is no means for me to explain to the end user what information or access is granted to the end user when joining accounts.

    This creates a few big problems, policy makers have to decide on a catch all solution which either favors its users or people developing for it. Second, I have no means as a developer to explain what the connection is for. I am given a section when registering an application to explain what it is, and even that is absent from the 'connect' splash page.

    I would really prefer it if there was a permission matrix which allows a developer to specifically delare which functionalities are reqested for usage. And in turn that same permission matrix can be used to explain to the end user before they connect, exactly what connecting is all about.

    No Client wants to authenticate with a third party application if it is going to start re tweeting to everybody else, or posting their test scores without their permission, or erasing thier followers, or sending DMS on thier behalf. I (as a tweeter) want to know what a strange 3rd party account website wants access to my account for. The problem seems to be partially resolved on a website like the Huffington past when it says they will post to your timeline, but I think it should be clearer, as in the future, I would hope there would be a real means to access the users email address, and a clear indication to the end user that its something being requested, and I as a developer have the option to provide a brief description as to what the connection is about, plus expanding the app registration to a fuller matrix, beyond the read and write dual option it currently is.
    Are you sure you want to
    Your message goes here
  • Slide 13 is useful, it should be on the Twitter instruction page.
    Are you sure you want to
    Your message goes here
  • When providing directions, keep people guessing, it's a sure way to make the standard fail... Give them 3 generic keys, tell them to hash with the 'secret one', give the others cute names like consumer. Force them to encrypt with public keys like 'Anonymous', reveal the algorithm in the get vars, advise POST over https, but allow GET over http, claim it's the future...

    Guys, this is clearly the worst attempt at a standard I have ever seen, sorry...

    It's not a standard, it's an advisory, and nobody seems to understand it's purpose, especially anyone writing the 'Help' manuals...
    Are you sure you want to
    Your message goes here
No Downloads

Views

Total Views
10,911
On Slideshare
0
From Embeds
0
Number of Embeds
1

Actions

Shares
Downloads
92
Comments
10
Likes
20

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide


























Transcript

  • 1. Too many secrets but never enough. by Raffi Krikorian & Taylor Singletary Questions? http://bit.ly/chirpoauth #chirpoauth
  • 2. OAuth is a dance.
  • 3. OAuth Libraries don’t always work right or won’t bend to your will easily. Sometimes you’ve got to get your hands dirty and fix them.
  • 4. All OAuth requests are similar at their core. The rules really don’t change.
  • 5. The signature base string.
  • 6. httpMethod + "&" + url_encode( base_uri ) + "&" + sorted_query_params.each { | k, v | url_encode ( k ) + "%3D" + url_encode ( v ) }.join("%26")
  • 7. httpMethod + "&" + url_encode( base_uri ) + "&" + sorted_query_params.each { | k, v | url_encode ( k ) + "%3D" + url_encode ( v ) }.join("%26")
  • 8. Signing requests.
  • 9. Signing an OAuth request is easier than you think. Take that signature base string, then sign it using HMAC-SHA1 and the proper signing key
  • 10. The proper signing key is a pain point. The access token step, and any resource requests on a user’s behalf utilizes OAuth tokens and secrets to create a composite signing key.
  • 11. Two-legged OAuth requests are requests that don’t require a user or oauth_token. Asking for a request token is actually a two-legged OAuth request.
  • 12. The algorithm for determining what your “signing key” is url_encode( consumer_secret ) + "&" + url_encode( oauth_token_secret || nil )
  • 13. The algorithm for determining what your “signing key” is With an oauth_token_secret signing_key = “abcd&efgh” Without an oauth_token_secret signing_key = “abcd&”
  • 14. the OAuth 1.0A Request Cycle
  • 15. xAuth & OAuth Echo
  • 16. xAuth in Ruby def get_access_token_with_xauth(login, password) consumer = initiate_oauth_consumer_object options = {} options[:x_auth_username] = login options[:x_auth_password] = password options[:x_auth_mode] = "client_auth" url = "https://api.twitter.com/oauth/access_token" response = consumer.token_request(:post, url, nil, {}, options) @access_token = OAuth::AccessToken.from_hash(consumer, response) end
  • 17. Working with OAuth Libraries Most OAuth Libraries are similar
  • 18. Advice • Learn how to specify HTTP headers explicitly in your OAuth implementation • Master the core components of your OAuth libraries. Follow the code path through so you understand the proper places to introduce different behavior.
  • 19. Truth & Reconciliation
  • 20. When things go wrong.
  • 21. the OAuth Dancer ( hold me closer )
  • 22. the OAuth Dancer • Nearly complete solution for testing REST-based API requests with OAuth 1.0A authentication. • Examine the signature base string, authorization headers, and oodles more debug information about requests. • Supports xAuth and two-legged OAuth. • Out-of-band (PIN) support coming soon. • Under perpetual development. OAuth 2.0 support on the way. • Very useful for creating comparative examples, testing internal OAuth implementations, and more. http://bit.ly/oauth-dancer
  • 23. What’s on the horizon? Q&A
  • 24. Some links OAuth Zero to Hero About OAuth Echo Beginner’s Guide to OAuth Twitter xAuth OAuth Dancer