OAuth: demystified (hopefully)
•
18 gefällt mir•5,357 views
My presentation outlining and explaining the core concepts behind OAuth, presented to the online ColdFusion Meetup June 9th 2011 and at Scotch on the Rocks, 3rd March 2011
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Andere mochten auch
Andere mochten auch (13)
Ähnlich wie OAuth: demystified (hopefully)
Ähnlich wie OAuth: demystified (hopefully) (20)
Mehr von Matt Gifford
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
OAuth: demystified (hopefully)
- 1. OAuth: demystified (hopefully) Matt Gifford aka coldfumonkeh http://www.mattgifford.co.uk
- 2. Matt Gifford aka coldfumonkeh
- 3. Matt Gifford aka coldfumonkeh ColdFusion / RIA
- 4. Matt Gifford aka coldfumonkeh ColdFusion / RIA Author
- 5. Matt Gifford aka coldfumonkeh ColdFusion / RIA Author Coffee Lover
- 6. Matt Giffordaka coldfumonkeh ColdFusion / RIA Author Coffee Lover blog at mattgifford.co.uk
- 7. Matt Gifford aka coldfumonkeh ColdFusion / RIA Author Coffee Lover blog at mattgifford.co.uk tweet @coldfumonkeh
- 8. Matt Gifford aka coldfumonkeh ColdFusion / RIA Author Coffee Lover blog at mattgifford.co.uk tweet @coldfumonkeh work at Fuzzy Orange
- 10. Why Are We Here? Very good question..
- 17. Have You Ever... dealt with user authentication?
- 18. Have You Ever... shared data through an external API?
- 19. Have You Ever... received spam emails asking for personal details?
- 20. Have You Ever... been spanked by an air stewardess holding a wet kipper whilst she called you ‘Betsie’?
- 21. Have You Ever... been spanked by an air stewardess holding a wet kipper whilst she called you ‘Betsie’?
- 22. As A Developer You... (should) want to keep your clients / users happy
- 23. As A Developer You... (should) aim to make integration, UX and UI as easy as possible for users
- 24. As A Developer You... (should) make sure that user’s data is secure and protected wherever possible
- 26. I need your clothes, boots and your email address
- 27. The password anti-pattern
- 28. Access Via Email
- 31. Nothing To See Here
- 33. Your Email = You
- 35. Ideally, we shouldn’t have to give these out or ask for them...
- 36. Email addresses and passwords are valuable
- 37. So... how can we stop asking for this information?
- 38. So... how can we delegate access to obtain restricted information without bringing down a world of pain upon ourselves?
- 40. What is OAuth?
- 41. What is OAuth? A simple open standard for secure API authentication
- 43. Who Can Use It? Service Providers offering a web service or API that requires authentication to access restricted data for a number of functions / methods
- 44. Who Can Use It? Consumers who wish to access that particular API or web service and wish to use a standardised method of authentication
- 46. Who Has Implemented OAuth? Twitter, Google, Meetup.com, Netflix, TripIt, Yahoo!, Evernote, Vimeo ... and many more
- 49. Sharing a single Identity with numerous consumers
- 50. Sharing a single Share data Identity with without sharing numerous your identity consumers
- 57. Let’s Get Stuck In delegated authorisation using tokens
- 58. The Love Triangle End User Consumer Service Provider
- 59. As Easy As This
- 61. The Dancers Fred - the end user Twitter - the Service Provider LinkedIn - the Consumer
- 62. The Steps consumer provider asks for a request token
- 63. The Steps consumer provider asks for a request token creates and returns a new request token
- 64. The Steps consumer provider asks for a request token creates and returns a new request token redirects user to provider with token in url
- 65. The Steps consumer provider asks for a request token creates and returns a new request token redirects user to provider with token in url user selects preferences and approves auth
- 66. The Steps consumer provider asks for a request token creates and returns a new request token redirects user to provider with token in url user selects preferences and approves auth redirected back to consumer with request token
- 67. The Steps consumer provider asks for a request token creates and returns a new request token redirects user to provider with token in url user selects preferences and approves auth redirected back to consumer with request token consumer wants to trade request token for access
- 68. The Steps consumer provider asks for a request token creates and returns a new request token redirects user to provider with token in url user selects preferences and approves auth redirected back to consumer with request token consumer wants to trade request token for access provisional request token traded for access token
- 69. The Steps consumer provider asks for a request token creates and returns a new request token redirects user to provider with token in url user selects preferences and approves auth redirected back to consumer with request token consumer wants to trade request token for access provisional request token consumer saves the traded for access token access token for the user
- 71. Breaking It Down Even More
- 72. 1 - Show Intent “LinkedIn is pretty cool. I want people to read more from me... I want them to read my status updates from Twitter. Can you access my updates for me, please?” “I certainly can, but I need to ask Twitter for permission before I can continue. Hold on..”
- 73. 2 - Request a Token “Hey Twitter, you overloaded piece of awesomeness. Please can I have a Request Token?” “LinkedIn, you corporate beast! Of course you can. Your Request Token is 9iKot2y5UQTDlS2V and your secret is 1Hv0pzNXMXdEfBd.”
- 74. 3 - Authorize The Request “OK, Fred. Right, can you go to Twitter and authorize the Request Token 9iKot2y5UQTDlS2V, please? Once that’s done, I’ll be able to access your status updates.” “OK”
- 75. 3 - Authorize The Request “Hey Twitter. I want to authorize the Request Token 9iKot2y5UQTDlS2V” “To confirm, you want to authorize LinkedIn to access your status updates. You’re happy with that?”
- 76. 3 - Authorize The Request “That’s just what I wanted, yes.” “Sweet! Tell LinkedIn you authorized it with me.”
- 77. 3 - Authorize The Request “Right.. Twitter knows I want you to do stuff for me. Everything’s set for you.” “Nice work, Fred. I’ll go and speak to Twitter now.”
- 78. 4 - Exchange the Token “Please can I exchange Request Token 9iKot2y5UQTDlS2V for an Access Token?” “No worries. Your Access Token is 94S3sJVmuuxSPiZz and your Secret is 4Fc8bwdKNGSM0iNe.”
- 79. 5 - Get Restricted Data “Awesome. Now I have those details, please can you give me the status updates that are owned by Access Token 94S3sJVmuuxSPiZz?” “Of course. Here you go...”
- 80. Quite Simple When You Put It Like That I know, right?
- 81. LinkedIn didn’t need to know Fred’s Twitter account details His identity was kept secret; it wasn’t important to access the data. What was important was his permission to proceed.
- 84. Even Simpler (kind of)
- 85. Even Simpler (kind of) 1 - Obtain a Request Token
- 86. Even Simpler (kind of) 1 - Obtain a Request Token 2 - User authorizes the Request Token
- 87. Even Simpler (kind of) 1 - Obtain a Request Token 2 - User authorizes the Request Token 3 - Exchange Request Token for Access token
- 88. Even Simpler (kind of) 1 - Obtain a Request Token 2 - User authorizes the Request Token 3 - Exchange Request Token for Access token 4 - Use Access Token to obtain the protected resources
- 89. What Does The User Experience?
- 93. The OAuth ‘Dance’ with different systems web applications desktop applications out of band applications
- 94. The Set Up where documentation is the best thing you can wish for
- 96. Registering a Consumer application
- 100. The Consumer the Consumer Key and Consumer Secret
- 101. The Tokens the Token Key and Token Secret
- 102. Let’s Get Stuck In making a request
- 104. An Example Request you need: HTTP Method Request URI (endpoint) oauth_callback oauth_consumer_key oauth_nonce oauth_signature_method oauth_timestamp oauth_version
- 105. Parameters oauth_*
- 109. Parameters oauth_signature_method="HMAC-SHA1" oauth_version="1.0" oauth_signature="tRMTYa%2FWM%3D"
- 111. Signature Base String the key to the authentication
- 112. What is the signature? a consistent reproducible concatenation of the request elements into a single string
- 113. Cryptographic Signature Signature Base String Consumer Secret
- 114. Cryptographic Signature Signature Base String Consumer Secret Signature
- 115. Cryptographic Signature Signature Base String Consumer Secret Signature sig=yourSignatureStr
- 116. Cryptographic Signature Signature Base String Consumer Secret Signature base=foobar&sig=yourSignatureStr
- 117. Parameters oauth_signature_method="HMAC-SHA1" oauth_version="1.0" oauth_signature="tRMTYa%2FWM%3D"
- 118. Request Example GET /1/statuses/mentions.json?count=5 HTTP/1.1 Host: api.twitter.com:80
- 119. Request Example With OAuth GET /1/statuses/mentions.json?count=5 HTTP/1.1 Host: api.twitter.com:80 Authorization: OAuth realm="" oauth_consumer_key="dpf43f3p2l4k3l03" oauth_token="nnch734d00sl2jdk" oauth_nonce="kllo9940pd9333jh" oauth_timestamp="1191242096" oauth_signature_method="HMAC-SHA1" oauth_version="1.0" oauth_signature="tR3%2BTy81lMeYAr%2FFid0kMTYa%2FWM%3D" Signature Base String GET&http%3A%2F%2Fapi.twitter.com%2F1%2Fstatuses%2Fmentions.json?count %3D5%26%26oauth_consumer_key%3Ddpf43f3p2l4k3l03%26oauth_nonce %3Dkllo9940pd9333jh%26oauth_signature_method%3DHMAC- SHA1%26oauth_timestamp%3D1191242096%26oauth_token%3Dnnch734d00sl2jdk %26oauth_version%3D1.0%26size%3Doriginal
- 120. HTTP Request Method GET /1/statuses/mentions.json?count=5 HTTP/1.1 Host: api.twitter.com:80 Authorization: OAuth realm="" oauth_consumer_key="dpf43f3p2l4k3l03" oauth_token="nnch734d00sl2jdk" oauth_nonce="kllo9940pd9333jh" oauth_timestamp="1191242096" oauth_signature_method="HMAC-SHA1" oauth_version="1.0" oauth_signature="tR3%2BTy81lMeYAr%2FFid0kMTYa%2FWM%3D" Signature Base String GET&http%3A%2F%2Fapi.twitter.com%2F1%2Fstatuses%2Fmentions.json?count %3D5%26%26oauth_consumer_key%3Ddpf43f3p2l4k3l03%26oauth_nonce %3Dkllo9940pd9333jh%26oauth_signature_method%3DHMAC- SHA1%26oauth_timestamp%3D1191242096%26oauth_token%3Dnnch734d00sl2jdk %26oauth_version%3D1.0%26size%3Doriginal
- 121. Request URI GET /1/statuses/mentions.json?count=5 HTTP/1.1 Host: api.twitter.com:80 Authorization: OAuth realm="" oauth_consumer_key="dpf43f3p2l4k3l03" oauth_token="nnch734d00sl2jdk" oauth_nonce="kllo9940pd9333jh" oauth_timestamp="1191242096" oauth_signature_method="HMAC-SHA1" oauth_version="1.0" oauth_signature="tR3%2BTy81lMeYAr%2FFid0kMTYa%2FWM%3D" Signature Base String GET&http%3A%2F%2Fapi.twitter.com%2F1%2Fstatuses%2Fmentions.json?count %3D5%26%26oauth_consumer_key%3Ddpf43f3p2l4k3l03%26oauth_nonce %3Dkllo9940pd9333jh%26oauth_signature_method%3DHMAC- SHA1%26oauth_timestamp%3D1191242096%26oauth_token%3Dnnch734d00sl2jdk %26oauth_version%3D1.0%26size%3Doriginal
- 122. Request Parameters GET /1/statuses/mentions.json?count=5 HTTP/1.1 Host: api.twitter.com:80 Authorization: OAuth realm="" oauth_consumer_key="dpf43f3p2l4k3l03" oauth_token="nnch734d00sl2jdk" oauth_nonce="kllo9940pd9333jh" oauth_timestamp="1191242096" oauth_signature_method="HMAC-SHA1" oauth_version="1.0" oauth_signature="tR3%2BTy81lMeYAr%2FFid0kMTYa%2FWM%3D" Signature Base String GET&http%3A%2F%2Fapi.twitter.com%2F1%2Fstatuses%2Fmentions.json?count %3D5%26%26oauth_consumer_key%3Ddpf43f3p2l4k3l03%26oauth_nonce %3Dkllo9940pd9333jh%26oauth_signature_method%3DHMAC- SHA1%26oauth_timestamp%3D1191242096%26oauth_token%3Dnnch734d00sl2jdk %26oauth_version%3D1.0%26size%3Doriginal
- 123. HTTP Request Example GET /1/statuses/mentions.json?count=5 HTTP/1.1 Host: api.twitter.com:80 Authorization: OAuth realm="" oauth_consumer_key="dpf43f3p2l4k3l03" oauth_token="nnch734d00sl2jdk" oauth_nonce="kllo9940pd9333jh" oauth_timestamp="1191242096" oauth_signature_method="HMAC-SHA1" oauth_version="1.0" oauth_signature="tR3%2BTy81lMeYAr%2FFid0kMTYa%2FWM%3D" Signature Base String HMAC-SHA1(GET&http%3A%2F%2Fapi.twitter.com%2F1%2Fstatuses %2Fmentions.json?count%3D5%26%26oauth_consumer_key %3Ddpf43f3p2l4k3l03%26oauth_nonce%3Dkllo9940pd9333jh %26oauth_signature_method%3DHMAC-SHA1%26oauth_timestamp %3D1191242096%26oauth_token%3Dnnch734d00sl2jdk%26oauth_version %3D1.0%26size%3Doriginal)
- 125. An Authorisation In Action with monkehTweets
- 131. Flavours
- 132. Flavours OAuth
- 133. Flavours OAuth xAuth
- 134. Flavours OAuth xAuth OAuth Echo
- 135. Flavours OAuth xAuth OAuth Echo and other variations
- 136. Benefits to OAuth
- 137. Benefits to OAuth a standardised protocol that is becoming widely implemented by many providers
- 138. Benefits to OAuth a standardised protocol that is becoming widely implemented by many providers user has control over access and can easily revoke consumers and application privileges
- 139. Benefits to OAuth a standardised protocol that is becoming widely implemented by many providers user has control over access and can easily revoke consumers and application privileges ability to track usage and statistics due to the access tokens
- 140. Benefits to OAuth a standardised protocol that is becoming widely implemented by many providers user has control over access and can easily revoke consumers and application privileges ability to track usage and statistics due to the access tokens many open-source libraries and clients available to use
- 141. Benefits to OAuth no personal information has been passed around
- 142. Issues with OAuth
- 143. Issues with OAuth documentation could be much better
- 144. Issues with OAuth documentation could be much better harder to implement that basic authentication
- 145. Issues with OAuth documentation could be much better harder to implement that basic authentication variations on the principle already exist
- 146. Issues with OAuth documentation could be much better harder to implement that basic authentication variations on the principle already exist does not solve brute force attacks or phishing
- 147. Want To Be A Service Provider? who doesn’t!
- 148. Want To Be A Service Provider? http://oauth.riaforge.org
- 152. As A Developer You... (can) make integration, UX and UI as easy as possible for users by not-overcomplicating the process and the content, keeping it simple and worded succinctly to help them understand the process without scaring them
- 153. As A Developer You... (can) make sure that user’s data is secure and protected wherever possible by ensuring that you only store what you need to store, and keep them safe and protected at all times
- 154. As A Developer You... (can) keep your clients / users happy by ensuring that you make it simple, straight forward and secure for them
- 155. Privacy is Freedom
- 159. Links & Stuff http://oauth.net http://oauth.net/core/1.0 http://oauth.riaforge.org http://monkehtweet.riaforge.org
- 160. OAuth: demystified (hopefully) Matt Gifford aka coldfumonkeh http://www.mattgifford.co.uk
Hinweis der Redaktion
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- Privacy. It’s a tricky idea. It’s really to try and protect the interests and information of our users. As they want. \n\n
- Or sometimes what we do is provide the perception of privacy. This is what a privacy policy is, Nobody reads it, so what it really does is provide the perception that there is privacy. \n
- Many users don’t want to appear in public at all, or they want to be able to delete their users and associated information. Perhaps they don’t want everybody to know they’re in the furries flickr group. \n
- Beyond problems with corporations and large enterprise sites wanting to obtain your data for various reasons, you’ve got the hacker problem. They really want to get at our users and systems. In all of our work we’ve got to think about what kinds of attacks we might face within a production environment. \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- Users data is important, user access is important, protecting these users is a freedom. Not totally dis-similar to the free software freedoms. We need to create systems which by default, transparently do the right thing by our users. If you engineer a system to protect privacy, then you are setting the rules of the game. It’s tremendous power and a tremendous responsibility. \n
- \n
- \n
- Right now we use email as the primary way of logging in to systems. It’s the core of the identity system online right now. \n
- Right now we use email as the primary way of logging in to systems. It’s the core of the identity system online right now. \n
- Instantly raises questions about privacy policy and the protection of individual’s security and data.\n
- We are allowing services to access our personal information and hold our passwords, which should be sacred and kept by only the privileged few... yourself, essentially.\n
- We are allowing services to access our personal information and hold our passwords, which should be sacred and kept by only the privileged few... yourself, essentially.\n
- The majority of people use a single email account for everything. The protection of this email is very important. \n\n
- You’ll find your personal information runs the risk of being taken.. including any financial accounts that you may hold.. (paypal transactions etc)\n
- \n
- \n
- \n
- \n
- There are many authorisation systems that do not ask for (or require) email addresses or passwords. Each one manages a similar process and practice for security, although in slightly different ways.\n\nOAuth seems to have reached the top of the pile of accepted authentication processes and is starting to become much more of a widely used protocol to delegate authentication.\n
- Many luxury cars come with a valet key. It is a special key you give the parking attendant and unlike your regular key, will only allow the car to be driven a short distance while blocking access to the trunk and the onboard cell phone. Regardless of the restrictions the valet key imposes, the idea is very clever. You give someone limited access to your car with a special key, while using another key to unlock everything else\n\nIt allows users to share their private resources (e.g. photos, videos, contact lists) stored on one site with another site without having to hand out their credentials, typically username and password.\n\nOAuth allows users to hand out tokens instead of credentials to their data hosted by a given service provider. Each token grants access to a specific site (e.g. a video editing site) for specific resources (e.g. just videos from a specific album) and for a defined duration (e.g. the next 2 hours). This allows a user to grant a third party site access to their information stored with another service provider, without sharing their access permissions or the full extent of their data.\n
- What are these token things we talk about? There’re little things we use to represent access, kind of like a barrier token or ticket to get into the underground. Each token is unique. More like symbols, which can be used to represent something without it being the thing. \n
- Ultimately, the end users (us) use the services, but the majority of the time we are not aware.\n
- Ultimately, the end users (us) use the services, but the majority of the time we are not aware.\n
- Who is using it at the moment?\n
- Who is using it at the moment?\n
- Are the two not the same? Why have both?\n
- Both protocols are similar in many ways.. they both move users between consumer and service provider. OpenID claims to own the URL.. OAuth claims to own the resource\n\nOpenID is an open standard that describes how users can be authenticated in a decentralized manner, obviating the need for services to provide their own ad hoc systems and allowing users to consolidate their digital identities.[1]\n
- Both protocols are similar in many ways.. they both move users between consumer and service provider. OpenID claims to own the URL.. OAuth claims to own the resource\n\nOpenID is an open standard that describes how users can be authenticated in a decentralized manner, obviating the need for services to provide their own ad hoc systems and allowing users to consolidate their digital identities.[1]\n
- So, what is the benefit of OAuth? How easy is it? Let’s take a look at Twitter and how they used to implement API access, and how they do it now..\n
- In Basic Authentication you need only provide a "return address" (the username and password), and the recipient's address (the resource you are accessing) -- occasionally stuffing the envelope with some data that is pertinent to the API request you are making. \nAspects of Basic Authentication with the Twitter API\nThe client application must store the user's login and password\nThe client application must send the user's login and password with every request\nIf the user's password changes, the client application must acquire a new password for the user\nThe user has no means to discover which basic auth-based apps have their login and password\nThe user has no ability to restrict an application from using their account after giving their login and password\nThe client application has a very weak identity within the Twitter ecosystem.\nPOST variables, query parameters, and the URL of the request can be modified at any stage of the request cycle without invalidating the request\nReplayed requests are not preventable\n\n
- So, essentially basic authentication can be thought of like this.\n
- \n
- OAuth Authentication is a bit more complex in this metaphor. While you still address the envelope to the same recipient (the resource), you identify your request as coming from both the user performing the request and your application that's working on behalf of the user. In addition, you must provide a "post mark" of sorts, describing the time the "letter" was sent and the actual contents of the envelope. In some ways, this is the biggest difference between the access methods.\nAspects of OAuth Authentication with the Twitter API\nThe client application doesn't need to store a login and password\nThe client application delegates authorization to a trusted location, namely https://api.twitter.com/oauth/authorize\nThe client application sends an access token representing the user with each request instead of a login & password\nPOST variables, query parameters, and the URL of the request must remain intact for a request to successfully complete (the oauth_signature cannot be verified unless all elements of the request retain their original qualities at the time of signature generation)\nIf the user's password changes, the client application continues functioning\nThe user is in control of what applications may act on their behalf and can remove authorization at any time\nYour application is a known entity in the ecosystem, with benefits both realized and to come in the area of analytics, attribution, and more.\nReplayed requests are prevented by a unique identifier for each request (the oauth_nonce)\n\n
- Whereas OAuth can be thought of like this.\n
- \n
- All this is to say that OAuth is like a love triangle. That is to say that the relationship between the provider, end user, and consumer is a love triangle. Each part communicates with both of the other parts. \n\nThe original idea of OAuth would be that it’s super simple, clear, everybody could read the standard and understand. It was nice and clear. Little by little in the standards process the standards people from IETF and W3C got involved. Now the spec is full of diagrams like... THIS!\n
- \n
- \n
- \n
- the application asks for a request token\n
- the application asks for a request token\nla aplicación inicia el\nintercambio del\nrequest token\n
- the application asks for a request token\nla aplicación inicia el\nintercambio del\nrequest token\n
- the application asks for a request token\nla aplicación inicia el\nintercambio del\nrequest token\n
- the application asks for a request token\nla aplicación inicia el\nintercambio del\nrequest token\n
- the application asks for a request token\nla aplicación inicia el\nintercambio del\nrequest token\n
- the application asks for a request token\nla aplicación inicia el\nintercambio del\nrequest token\n
- the application asks for a request token\n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- That whole interaction makes it slightly easier to see how the request was being made... The tokens were being passed between the consumer and service provider, and it was those tokens they were using for dealing with a specific individual.. again, NO names, personal information or other details were passed between the two parties; purely a token (a reference or symbol) to that particular individual. \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- That was the token dance for web applications. There is a similar but slightly different process for desktop and out of band applications like browserless mobile phones and embedded systems.\n
- Service provider gives documentation of authorization URLs and methods. Consumer registers an application with the service provider\n
- Important information that Service Providers MUST give the consumers... (or SHOULD, at any rate)\n\nRequest token endpoint\nAuthorization endpoint\nAccess token endpoint\nAccepted request method(s) (GET, POST, PUT, etc...)\nSignature method(s)\nExtra parameters (non-oauth)\nAny specific notes about OAuth for that provider (they may all have different ‘rules’)\n
- \n
- \n
- \n
- \n
- Consumer Key\n• assigned during consumer registration\n• which will get passed as a request parameter\n\nConsumer Secret\n• assigned during consumer registration and used for signing (e.g. HMAC-SHA1)\n
- specific to the user, not the consumer or provider\n\ntoken key\n• unique string granted by service provider\n• passed as a request parameter\n• same variable name (oauth_token_key) for\nboth request and access type tokens\n\ntoken secret\n• also granted by service provider\n• same variable name (oauth_token_secret)\nfor both request and access type tokens\n
- \n
- Building any OAuth request in theory is quite simple. In theory. There is a short list of standard ingredients that you need to include in your recipe to ensure you have the base created. You MAY have optional extra ingredients (depending on the service provider and their requirements) but above all, you will NEED to create your request signature to sign it and add in the extra level of security, which we’ll cover here. Let’s have a look at what we need...\n
- Here is our list of ‘standard’ ingredients. Quite a simple list in the grand scheme of things. Let’s have a look at them to clarify\n
- All of the oauth params start with the oauth_* prefix. \n
- As we saw before, there are keys (tokens) and secrets. The consumer application or library itself has a token secret part, in addition to a user’s access token and secret. The key is passed with each request, and the consumer secret is used for signing every request.\n\n
- The tokens are just random strings which should be unique.\n
- Then we require that each request have a timestamp and nonce. The timestamp is an integer which needs to increment and it’s the number of seconds since Unix epoch (unless otherwise specified\nby service provider). It must be equal or greater than previous request.\nThe nonce is a unique number/string which can’t be reused with the same timestamp. The combination of these, and the signing prevents replay attacks.\n
- The last couple define the signing method. There are three options for signing..\nRSA-SHA1 or PLAINTEXT, but it’s usually HMAC-SHA1 (which seems to be the standard preferred method). Then the version of oauth, which despite the current standard being 1.0a the standard says you should still say 1.0. Then the actual signature of the request.\n\n
- \n
- The signature itself forms a critically important role in the security of the OAuth request protocol, and can be a difficult beast to tame.\n
- The trick with all the delegated token authorization systems is that they DON’T pass the password with each request. They use a base string coupled with a secret. The secret is used in the signature but is not passed over the wire in the request (so it’s not visible). \n
- So what does this look like, well we use the signature base string and the consumer secret. We’ll look at how to create the actual base string next.\n
- We use the combination of the signature base string and then the consumer secret as the hash key to sign the string.\n
- Then that signature is created as a param which can be passed in the requests, typically within the header of the request, which we will see.. although you could send via URL query params too.\n
- So you end up something like this. The base request and the hashed signature are passed over the wire. The consumer secret is kept on both ends to verify the signature. It is never displayed or passed through any of the requests.\n
- So, back to the parameters! You have seen in essence how the signature parameter is created. Let’s have a look at a sample request to try to better understand the building blocks and to see how the ingredients for our OAuth recipe have been used.\n
- \n
- Where is this\ninformation passed?\n• HTTP Authorization header\n• HTTP POST request body (form params)\n• URL query string parameters\n
- \n
- \n
- \n
- \n
- By creating a signature in this manner, you’re able to successfully sign your requests and then complete your call for data.\n
- \n
- \n
- \n
- \n
- \n
- \n
- xAuth is still OAuth. You still need to master how to send signed requests to Twitter.\nxAuth provides a way for desktop and mobile applications to exchange a username and password for an OAuth access token. Once the access token is retrieved, xAuth-enabled developers should dispose of the login and password corresponding to the user.\n\nxAuth allows desktop and mobile applications to skip the request_token and authorize steps and jump right to the access_token step.\n\nOAuth Echo is a means to securely delegate OAuth authorization with a third party while interacting with an API. Within the Twitter ecosystem, we use OAuth Echo as a means to allow your application to use services such as Twitpic and yfrog.\nThere are four parties involved in this interaction:\nthe User who is using Twitter through a particular, authorized Twitter application\nthe Consumer, or the Twitter application that is attempting to interact with the 3rd party media provider (e.g. the photo sharing site)\nthe Delegator, or the 3rd party media provider; and\nthe Service Provider a.k.a. Twitter itself.\nEssentially, you will be preparing a request for the delegator to send to the Twitter API on your application and user's behalf. You'll be sticking what would otherwise be a signed OAuth request into an HTTP header and asking the delegator to send that request to Twitter after completing the intermediary operation.\n\n\n
- xAuth is still OAuth. You still need to master how to send signed requests to Twitter.\nxAuth provides a way for desktop and mobile applications to exchange a username and password for an OAuth access token. Once the access token is retrieved, xAuth-enabled developers should dispose of the login and password corresponding to the user.\n\nxAuth allows desktop and mobile applications to skip the request_token and authorize steps and jump right to the access_token step.\n\nOAuth Echo is a means to securely delegate OAuth authorization with a third party while interacting with an API. Within the Twitter ecosystem, we use OAuth Echo as a means to allow your application to use services such as Twitpic and yfrog.\nThere are four parties involved in this interaction:\nthe User who is using Twitter through a particular, authorized Twitter application\nthe Consumer, or the Twitter application that is attempting to interact with the 3rd party media provider (e.g. the photo sharing site)\nthe Delegator, or the 3rd party media provider; and\nthe Service Provider a.k.a. Twitter itself.\nEssentially, you will be preparing a request for the delegator to send to the Twitter API on your application and user's behalf. You'll be sticking what would otherwise be a signed OAuth request into an HTTP header and asking the delegator to send that request to Twitter after completing the intermediary operation.\n\n\n
- xAuth is still OAuth. You still need to master how to send signed requests to Twitter.\nxAuth provides a way for desktop and mobile applications to exchange a username and password for an OAuth access token. Once the access token is retrieved, xAuth-enabled developers should dispose of the login and password corresponding to the user.\n\nxAuth allows desktop and mobile applications to skip the request_token and authorize steps and jump right to the access_token step.\n\nOAuth Echo is a means to securely delegate OAuth authorization with a third party while interacting with an API. Within the Twitter ecosystem, we use OAuth Echo as a means to allow your application to use services such as Twitpic and yfrog.\nThere are four parties involved in this interaction:\nthe User who is using Twitter through a particular, authorized Twitter application\nthe Consumer, or the Twitter application that is attempting to interact with the 3rd party media provider (e.g. the photo sharing site)\nthe Delegator, or the 3rd party media provider; and\nthe Service Provider a.k.a. Twitter itself.\nEssentially, you will be preparing a request for the delegator to send to the Twitter API on your application and user's behalf. You'll be sticking what would otherwise be a signed OAuth request into an HTTP header and asking the delegator to send that request to Twitter after completing the intermediary operation.\n\n\n
- xAuth is still OAuth. You still need to master how to send signed requests to Twitter.\nxAuth provides a way for desktop and mobile applications to exchange a username and password for an OAuth access token. Once the access token is retrieved, xAuth-enabled developers should dispose of the login and password corresponding to the user.\n\nxAuth allows desktop and mobile applications to skip the request_token and authorize steps and jump right to the access_token step.\n\nOAuth Echo is a means to securely delegate OAuth authorization with a third party while interacting with an API. Within the Twitter ecosystem, we use OAuth Echo as a means to allow your application to use services such as Twitpic and yfrog.\nThere are four parties involved in this interaction:\nthe User who is using Twitter through a particular, authorized Twitter application\nthe Consumer, or the Twitter application that is attempting to interact with the 3rd party media provider (e.g. the photo sharing site)\nthe Delegator, or the 3rd party media provider; and\nthe Service Provider a.k.a. Twitter itself.\nEssentially, you will be preparing a request for the delegator to send to the Twitter API on your application and user's behalf. You'll be sticking what would otherwise be a signed OAuth request into an HTTP header and asking the delegator to send that request to Twitter after completing the intermediary operation.\n\n\n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- It’s very important that you have your forms which catch CSRF and XSS when you authorize an oauth app. Twitter messed this up for a bit, and you could authorize via oauth through an image in the page or javascript hack. That’s bad. Don’t do that. Cross-site request forgery, also known as a one-click attack or session riding and abbreviated as CSRF (pronounced sea-surf[1]) or XSRF, is a type of malicious exploit of awebsite whereby unauthorized commands are transmitted from a user that the website trusts.[2] Unlike cross-site scripting (XSS), which exploits the trust a user has for a particular site, CSRF exploits the trust that a site has in a user's browser.\n
- Another important thing to think about, is what not to log. We make a mistake by collecting all this ambient information we might not use. It might come back to bite us or our users. If we don’t collect data, hackers can’t get at it when they compromise our systems or when we get court orders. So implement a policy of selective logging. Just like you can do A/B testing for features, you can turn on logging to catch specific abuse cases or or performance issues. When in doubt, find a way to get what you want while storing less information. Make encryption be by default on. \n
- \n
- \n
- \n
- Users data is important, user access is important, protecting these users is a freedom. Not totally dis-similar to the free software freedoms. We need to create systems which by default, transparently do the right thing by our users. If you engineer a system to protect privacy, then you are setting the rules of the game. It’s tremendous power and a tremendous responsibility. \n
- github, Facebook Graphs API\n
- The important thing is to not let it overwhelm you.\n
- OAuth.. it’s not a black art, but the documentation does not help :)\n
- Some really useful links for you, should you wish to follow them to find out more.\n
- \n