Your SlideShare is downloading. ×
OAuth: demystified                            (hopefully)Matt Gifford         aka coldfumonkehhttp://www.mattgifford.co.uk
Matt Gifford       aka coldfumonkeh
Matt Gifford           aka coldfumonkehColdFusion / RIA
Matt Gifford           aka coldfumonkehColdFusion / RIAAuthor
Matt Gifford           aka coldfumonkehColdFusion / RIAAuthorCoffee Lover
Matt Giffordaka coldfumonkehColdFusion / RIAAuthorCoffee Loverblog atmattgifford.co.uk
Matt Gifford          aka coldfumonkehColdFusion / RIAAuthorCoffee Loverblog atmattgifford.co.uktweet @coldfumonkeh
Matt Gifford           aka coldfumonkehColdFusion / RIAAuthorCoffee Loverblog atmattgifford.co.uktweet @coldfumonkehwork a...
Why Are We Here?             Very good question..
Access and Privacy
Have You Ever...          dealt with user authentication?
Have You Ever...      shared data through an external API?
Have You Ever...         received spam emails asking for                       personal details?
Have You Ever...       been spanked by an air stewardess      holding a wet kipper whilst she called                      ...
Have You Ever...       been spanked by an air stewardess      holding a wet kipper whilst she called                      ...
As A Developer You...(should) want to keep your clients / users happy
As A Developer You... (should) aim to make integration, UX and UI as                     easy as possible for users
As A Developer You...(should)   make sure that user’s data is secure             and protected wherever possible
Privacy is Freedom
I need your  clothes, bootsand your email address
The password        anti-pattern
Access Via Email
Ruh-Roh, Shaggy...
Nothing To See Here
Comfortable With This?
Your Email = You
Privacy is Freedom
Ideally, we shouldn’t have to give these out orask for them...
Email addresses and passwords are valuable
So...  how can we stop asking for this information?
So...how can we delegate access to obtain restricted   information without bringing down a world of                       ...
What is OAuth?
What is OAuth?     A simple open standard for secure API                            authentication
Who Can Use It?Service Providers offering a web service or APIthat requires authentication to access restricteddata for a ...
Who Can Use It?Consumers who wish to access that particularAPI or web service and wish to use astandardised method of auth...
Who HasImplemented OAuth?
Who HasImplemented OAuth?  Twitter, Google, Meetup.com, Netflix, TripIt,                   Yahoo!, Evernote, Vimeo ...    ...
But What About...
Sharing a single Identity with  numerous  consumers
Sharing a single     Share data Identity with     without sharing  numerous          your identity  consumers
Let’s Get Stuck In  delegated authorisation              using tokens
The Love Triangle            End User Consumer              Service                       Provider
As Easy As This
The OAuth ‘Dance’
The Dancers        Fred - the end user        Twitter - the Service Provider        LinkedIn - the Consumer
The Steps      consumer              provider asks for a request token
The Steps      consumer                provider asks for a request token                            creates and returns   ...
The Steps      consumer                  provider asks for a request token                              creates and return...
The Steps      consumer                    provider asks for a request token                               creates and ret...
The Steps       consumer                    provider  asks for a request token                                creates and ...
The Steps       consumer                    provider  asks for a request token                                creates and ...
The Steps       consumer                     provider  asks for a request token                                 creates an...
The Steps       consumer                     provider  asks for a request token                                 creates an...
Breaking It Down Even More
1 - Show Intent          “LinkedIn is pretty cool. I want         people to read more from me... I           want them to ...
2 - Request a Token       “Hey Twitter, you overloaded piece       of awesomeness. Please can I have              a Reques...
3 - Authorize The Request         “OK, Fred. Right, can you go to        Twitter and authorize the Request        Token 9i...
3 - Authorize The Request        “Hey Twitter. I want to authorize the         Request Token 9iKot2y5UQTDlS2V”        “To ...
3 - Authorize The Request         “That’s just what I wanted, yes.”       “Sweet! Tell LinkedIn you authorized            ...
3 - Authorize The Request        “Right.. Twitter knows I want you to        do stuff for me. Everything’s set for        ...
4 - Exchange the Token         “Please can I exchange Request       Token 9iKot2y5UQTDlS2V for an Access                  ...
5 - Get Restricted Data           “Awesome. Now I have those        details, please can you give me the         status upd...
Quite Simple When YouPut It Like That                  I know, right?
LinkedIn didn’t need toknow Fred’s Twitteraccount details       His identity was kept secret; it wasn’t     important to a...
Even Simpler (kind of)
Even Simpler (kind of)1 - Obtain a Request Token
Even Simpler (kind of)1 - Obtain a Request Token2 - User authorizes the Request Token
Even Simpler (kind of)1 - Obtain a Request Token2 - User authorizes the Request Token3 - Exchange Request Token for Access...
Even Simpler (kind of)1 - Obtain a Request Token2 - User authorizes the Request Token3 - Exchange Request Token for Access...
What Does The UserExperience?
The OAuth ‘Dance’with different systems           web applications        desktop applications       out of band applicati...
The Set Up    where documentation     is the best thing you              can wish for
Registering a    Consumer application
The Consumer  the Consumer Key and       Consumer Secret
The Tokens      the Token Key and           Token Secret
Let’s Get Stuck In        making a request
An Example Requestyou need:HTTP MethodRequest URI (endpoint)oauth_callbackoauth_consumer_keyoauth_nonceoauth_signature_met...
Parametersoauth_*
Parametersoauth_consumer_keyoauth_consumer_secret
Parametersoauth_consumer_key="dpf43f3p2l4k3l03"oauth_token="nnch734d00sl2jdk"
Parametersoauth_nonce="kllo9940pd9333jh"oauth_timestamp="1191242096"
Parametersoauth_signature_method="HMAC-SHA1"oauth_version="1.0"oauth_signature="tRMTYa%2FWM%3D"
Signature Base Stringthe key to the authentication
What is the signature?a consistent reproducible concatenation of   the request elements into a single string
Cryptographic Signature Signature Base String   Consumer Secret
Cryptographic Signature Signature Base String   Consumer Secret             Signature
Cryptographic Signature Signature Base String    Consumer Secret             Signature                sig=yourSignatureStr
Cryptographic Signature Signature Base String    Consumer Secret             Signature   base=foobar&sig=yourSignatureStr
Parametersoauth_signature_method="HMAC-SHA1"oauth_version="1.0"oauth_signature="tRMTYa%2FWM%3D"
Request ExampleGET /1/statuses/mentions.json?count=5 HTTP/1.1Host: api.twitter.com:80
Request Example With OAuthGET /1/statuses/mentions.json?count=5 HTTP/1.1Host: api.twitter.com:80Authorization: OAuth realm...
HTTP Request MethodGET /1/statuses/mentions.json?count=5 HTTP/1.1Host: api.twitter.com:80Authorization: OAuth realm=""  oa...
Request URIGET /1/statuses/mentions.json?count=5 HTTP/1.1Host: api.twitter.com:80Authorization: OAuth realm=""  oauth_cons...
Request ParametersGET /1/statuses/mentions.json?count=5 HTTP/1.1Host: api.twitter.com:80Authorization: OAuth realm=""  oau...
HTTP Request ExampleGET /1/statuses/mentions.json?count=5 HTTP/1.1Host: api.twitter.com:80Authorization: OAuth realm=""  o...
An AuthorisationIn Action      with monkehTweets
Flavours
Flavours           OAuth
Flavours           OAuth           xAuth
Flavours             OAuth             xAuth           OAuth Echo
Flavours             OAuth             xAuth           OAuth Echo                  and other variations
Benefits to OAuth
Benefits to OAutha standardised protocol that is becoming widely               implemented by many providers
Benefits to OAutha standardised protocol that is becoming widely                implemented by many providers     user has...
Benefits to OAutha standardised protocol that is becoming widely                  implemented by many providers     user h...
Benefits to OAutha standardised protocol that is becoming widely                  implemented by many providers     user h...
Benefits to OAuth     no personal information has         been passed around
Issues with OAuth
Issues with OAuth      documentation could be much better
Issues with OAuth          documentation could be much better  harder to implement that basic authentication
Issues with OAuth          documentation could be much better  harder to implement that basic authentication         varia...
Issues with OAuth         documentation could be much better harder to implement that basic authentication        variatio...
Want To Be A Service Provider?              who doesn’t!
Want To Be A Service Provider?  http://oauth.riaforge.org
http://oauth.riaforge.org
As A Developer You...   (can) make integration, UX and UI as easy as                              possible for users   by ...
As A Developer You...  (can)     make sure that user’s data is secure              and protected wherever possibleby ensur...
As A Developer You...        (can) keep your clients / users happy  by ensuring that you make it simple, straight         ...
Privacy is Freedom
Links & Stuff             http://oauth.net        http://oauth.net/core/1.0        http://oauth.riaforge.org    http://mon...
OAuth: demystified                            (hopefully)Matt Gifford         aka coldfumonkehhttp://www.mattgifford.co.uk
OAuth: demystified (hopefully)
OAuth: demystified (hopefully)
OAuth: demystified (hopefully)
OAuth: demystified (hopefully)
OAuth: demystified (hopefully)
OAuth: demystified (hopefully)
OAuth: demystified (hopefully)
OAuth: demystified (hopefully)
OAuth: demystified (hopefully)
OAuth: demystified (hopefully)
OAuth: demystified (hopefully)
OAuth: demystified (hopefully)
OAuth: demystified (hopefully)
OAuth: demystified (hopefully)
OAuth: demystified (hopefully)
OAuth: demystified (hopefully)
OAuth: demystified (hopefully)
OAuth: demystified (hopefully)
OAuth: demystified (hopefully)
OAuth: demystified (hopefully)
OAuth: demystified (hopefully)
OAuth: demystified (hopefully)
OAuth: demystified (hopefully)
OAuth: demystified (hopefully)
OAuth: demystified (hopefully)
OAuth: demystified (hopefully)
OAuth: demystified (hopefully)
OAuth: demystified (hopefully)
OAuth: demystified (hopefully)
OAuth: demystified (hopefully)
OAuth: demystified (hopefully)
OAuth: demystified (hopefully)
OAuth: demystified (hopefully)
OAuth: demystified (hopefully)
OAuth: demystified (hopefully)
OAuth: demystified (hopefully)
OAuth: demystified (hopefully)
OAuth: demystified (hopefully)
OAuth: demystified (hopefully)
Upcoming SlideShare
Loading in...5
×

OAuth: demystified (hopefully)

5,195

Published on

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

Published in: Technology
0 Comments
16 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
5,195
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
0
Comments
0
Likes
16
Embeds 0
No embeds

No notes for slide
  • \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
  • Transcript of "OAuth: demystified (hopefully)"

    1. 1. OAuth: demystified (hopefully)Matt Gifford aka coldfumonkehhttp://www.mattgifford.co.uk
    2. 2. Matt Gifford aka coldfumonkeh
    3. 3. Matt Gifford aka coldfumonkehColdFusion / RIA
    4. 4. Matt Gifford aka coldfumonkehColdFusion / RIAAuthor
    5. 5. Matt Gifford aka coldfumonkehColdFusion / RIAAuthorCoffee Lover
    6. 6. Matt Giffordaka coldfumonkehColdFusion / RIAAuthorCoffee Loverblog atmattgifford.co.uk
    7. 7. Matt Gifford aka coldfumonkehColdFusion / RIAAuthorCoffee Loverblog atmattgifford.co.uktweet @coldfumonkeh
    8. 8. Matt Gifford aka coldfumonkehColdFusion / RIAAuthorCoffee Loverblog atmattgifford.co.uktweet @coldfumonkehwork at Fuzzy Orange
    9. 9. Why Are We Here? Very good question..
    10. 10. Access and Privacy
    11. 11. Have You Ever... dealt with user authentication?
    12. 12. Have You Ever... shared data through an external API?
    13. 13. Have You Ever... received spam emails asking for personal details?
    14. 14. Have You Ever... been spanked by an air stewardess holding a wet kipper whilst she called you ‘Betsie’?
    15. 15. Have You Ever... been spanked by an air stewardess holding a wet kipper whilst she called you ‘Betsie’?
    16. 16. As A Developer You...(should) want to keep your clients / users happy
    17. 17. As A Developer You... (should) aim to make integration, UX and UI as easy as possible for users
    18. 18. As A Developer You...(should) make sure that user’s data is secure and protected wherever possible
    19. 19. Privacy is Freedom
    20. 20. I need your clothes, bootsand your email address
    21. 21. The password anti-pattern
    22. 22. Access Via Email
    23. 23. Ruh-Roh, Shaggy...
    24. 24. Nothing To See Here
    25. 25. Comfortable With This?
    26. 26. Your Email = You
    27. 27. Privacy is Freedom
    28. 28. Ideally, we shouldn’t have to give these out orask for them...
    29. 29. Email addresses and passwords are valuable
    30. 30. So... how can we stop asking for this information?
    31. 31. So...how can we delegate access to obtain restricted information without bringing down a world of pain upon ourselves?
    32. 32. What is OAuth?
    33. 33. What is OAuth? A simple open standard for secure API authentication
    34. 34. Who Can Use It?Service Providers offering a web service or APIthat requires authentication to access restricteddata for a number of functions / methods
    35. 35. Who Can Use It?Consumers who wish to access that particularAPI or web service and wish to use astandardised method of authentication
    36. 36. Who HasImplemented OAuth?
    37. 37. Who HasImplemented OAuth? Twitter, Google, Meetup.com, Netflix, TripIt, Yahoo!, Evernote, Vimeo ... and many more
    38. 38. But What About...
    39. 39. Sharing a single Identity with numerous consumers
    40. 40. Sharing a single Share data Identity with without sharing numerous your identity consumers
    41. 41. Let’s Get Stuck In delegated authorisation using tokens
    42. 42. The Love Triangle End User Consumer Service Provider
    43. 43. As Easy As This
    44. 44. The OAuth ‘Dance’
    45. 45. The Dancers Fred - the end user Twitter - the Service Provider LinkedIn - the Consumer
    46. 46. The Steps consumer provider asks for a request token
    47. 47. The Steps consumer provider asks for a request token creates and returns a new request token
    48. 48. The Steps consumer provider asks for a request token creates and returns a new request token redirects user to provider with token in url
    49. 49. 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
    50. 50. 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 authredirected back to consumer with request token
    51. 51. 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 authredirected back to consumer with request token consumer wants to trade request token for access
    52. 52. 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 authredirected back to consumer with request token consumer wants to trade request token for access provisional request token traded for access token
    53. 53. 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 authredirected 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
    54. 54. Breaking It Down Even More
    55. 55. 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..”
    56. 56. 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.”
    57. 57. 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”
    58. 58. 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?”
    59. 59. 3 - Authorize The Request “That’s just what I wanted, yes.” “Sweet! Tell LinkedIn you authorized it with me.”
    60. 60. 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.”
    61. 61. 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.”
    62. 62. 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...”
    63. 63. Quite Simple When YouPut It Like That I know, right?
    64. 64. LinkedIn didn’t need toknow Fred’s Twitteraccount details His identity was kept secret; it wasn’t important to access the data. What was important was his permission to proceed.
    65. 65. Even Simpler (kind of)
    66. 66. Even Simpler (kind of)1 - Obtain a Request Token
    67. 67. Even Simpler (kind of)1 - Obtain a Request Token2 - User authorizes the Request Token
    68. 68. Even Simpler (kind of)1 - Obtain a Request Token2 - User authorizes the Request Token3 - Exchange Request Token for Access token
    69. 69. Even Simpler (kind of)1 - Obtain a Request Token2 - User authorizes the Request Token3 - Exchange Request Token for Access token4 - Use Access Token to obtain the protected resources
    70. 70. What Does The UserExperience?
    71. 71. The OAuth ‘Dance’with different systems web applications desktop applications out of band applications
    72. 72. The Set Up where documentation is the best thing you can wish for
    73. 73. Registering a Consumer application
    74. 74. The Consumer the Consumer Key and Consumer Secret
    75. 75. The Tokens the Token Key and Token Secret
    76. 76. Let’s Get Stuck In making a request
    77. 77. An Example Requestyou need:HTTP MethodRequest URI (endpoint)oauth_callbackoauth_consumer_keyoauth_nonceoauth_signature_methodoauth_timestampoauth_version
    78. 78. Parametersoauth_*
    79. 79. Parametersoauth_consumer_keyoauth_consumer_secret
    80. 80. Parametersoauth_consumer_key="dpf43f3p2l4k3l03"oauth_token="nnch734d00sl2jdk"
    81. 81. Parametersoauth_nonce="kllo9940pd9333jh"oauth_timestamp="1191242096"
    82. 82. Parametersoauth_signature_method="HMAC-SHA1"oauth_version="1.0"oauth_signature="tRMTYa%2FWM%3D"
    83. 83. Signature Base Stringthe key to the authentication
    84. 84. What is the signature?a consistent reproducible concatenation of the request elements into a single string
    85. 85. Cryptographic Signature Signature Base String Consumer Secret
    86. 86. Cryptographic Signature Signature Base String Consumer Secret Signature
    87. 87. Cryptographic Signature Signature Base String Consumer Secret Signature sig=yourSignatureStr
    88. 88. Cryptographic Signature Signature Base String Consumer Secret Signature base=foobar&sig=yourSignatureStr
    89. 89. Parametersoauth_signature_method="HMAC-SHA1"oauth_version="1.0"oauth_signature="tRMTYa%2FWM%3D"
    90. 90. Request ExampleGET /1/statuses/mentions.json?count=5 HTTP/1.1Host: api.twitter.com:80
    91. 91. Request Example With OAuthGET /1/statuses/mentions.json?count=5 HTTP/1.1Host: api.twitter.com:80Authorization: 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 StringGET&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
    92. 92. HTTP Request MethodGET /1/statuses/mentions.json?count=5 HTTP/1.1Host: api.twitter.com:80Authorization: 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 StringGET&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
    93. 93. Request URIGET /1/statuses/mentions.json?count=5 HTTP/1.1Host: api.twitter.com:80Authorization: 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 StringGET&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
    94. 94. Request ParametersGET /1/statuses/mentions.json?count=5 HTTP/1.1Host: api.twitter.com:80Authorization: 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 StringGET&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
    95. 95. HTTP Request ExampleGET /1/statuses/mentions.json?count=5 HTTP/1.1Host: api.twitter.com:80Authorization: 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 StringHMAC-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)
    96. 96. An AuthorisationIn Action with monkehTweets
    97. 97. Flavours
    98. 98. Flavours OAuth
    99. 99. Flavours OAuth xAuth
    100. 100. Flavours OAuth xAuth OAuth Echo
    101. 101. Flavours OAuth xAuth OAuth Echo and other variations
    102. 102. Benefits to OAuth
    103. 103. Benefits to OAutha standardised protocol that is becoming widely implemented by many providers
    104. 104. Benefits to OAutha standardised protocol that is becoming widely implemented by many providers user has control over access and can easily revoke consumers and application privileges
    105. 105. Benefits to OAutha 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
    106. 106. Benefits to OAutha 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 tokensmany open-source libraries and clients available to use
    107. 107. Benefits to OAuth no personal information has been passed around
    108. 108. Issues with OAuth
    109. 109. Issues with OAuth documentation could be much better
    110. 110. Issues with OAuth documentation could be much better harder to implement that basic authentication
    111. 111. Issues with OAuth documentation could be much better harder to implement that basic authentication variations on the principle already exist
    112. 112. 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
    113. 113. Want To Be A Service Provider? who doesn’t!
    114. 114. Want To Be A Service Provider? http://oauth.riaforge.org
    115. 115. http://oauth.riaforge.org
    116. 116. As A Developer You... (can) make integration, UX and UI as easy as possible for users by not-overcomplicating the process and thecontent, keeping it simple and worded succinctly to help them understand the process without scaring them
    117. 117. As A Developer You... (can) make sure that user’s data is secure and protected wherever possibleby ensuring that you only store what you need to store, and keep them safe and protected at all times
    118. 118. As A Developer You... (can) keep your clients / users happy by ensuring that you make it simple, straight forward and secure for them
    119. 119. Privacy is Freedom
    120. 120. Links & Stuff http://oauth.net http://oauth.net/core/1.0 http://oauth.riaforge.org http://monkehtweet.riaforge.org
    121. 121. OAuth: demystified (hopefully)Matt Gifford aka coldfumonkehhttp://www.mattgifford.co.uk

    ×