 All right, so can everyone hear me falling to good excellent So yeah, as Robert said, I'm Tim Rosenblatt the agile development director at cloud space Real quick before I get started Just wanted to say thank you, you know to we got sponsors you guys all the speakers I know how long it takes to put together these presentations Everyone's done a good job and in a special, you know, thanks to Robert and Jason for putting this all together I Also wanted to point out the logo. I absolutely love the logo. It's it's like if you come to access conference We will cut your head open and insert rails knowledge directly into your brain, and I think that's awesome It would definitely save me a lot of time reading books and blog articles, but maybe we can work on that for next year All right, so What is it's an awesome way to For users to give third-party services access to their data while reducing the risk involved in the whole process and During this whole presentation. I just want everyone to keep in mind, you know One of the real simple metaphors that's used actually on the OAuth site Is the idea of like a valet key for a car? You know Your real key obviously does everything with the car, but you can also have a valet key that doesn't open the trunk Doesn't open the glove compartment In some really, you know new fancy cars that the car won't even drive more than a few miles with the valet key and you know the analogy here is that it's Giving it's it's giving permission to something while still kind of keeping things under control So there's a few parts to the presentation first. I'm going to start with you know Really, what is OAuth what isn't OAuth and then why is OAuth even worth your time? After that we're gonna go through some code There's a really great tutorial written by Hella Brandegard and he's put together some great explanations on his site He's actually the one that wrote the OAuth gem that I'm going to be covering. So, you know, his stuff is the best way to go I'm going to give links to the original tutorials at the end of the presentation So don't worry about trying to copy down all the code. I just want everyone to get a sense of how Little code it takes to actually make this happen Then after that I'm going to do a quick rundown of what goes on behind the scenes in OAuth In, you know, true Ruby form the gem is going to take care of a lot of things that you as the developer Aren't going to have to worry about but I think it's really good to at least be aware of these things so that you know what's going on behind the scenes and You know, you can just have a much deeper understanding of that After that we're going to look at a few add-ons and extensions that will make OAuth work Better for you, depending on what it is exactly that you're trying to do with it Also If you got a piece of paper or more likely a laptop in front of you, please write down any notes you have during the presentation Happy to answer all of them at the end and I know how frustrating it can be to forget something mid presentation So with that, let's get started Who knows OAuth just by a show of hands. Who knows what OAuth is. All right, awesome So for those of you that do know a quick review for those of you that don't what is OAuth? Gotta love this case Awesome, awesome, this could be your crack So OAuth is a way to control access to things usually web services and APIs and things like that You know as Robert mentioned, let's take Twitter as an example There's tons of apps out there that will post data to your Twitter account And you know, how do they get access to your Twitter account? Well, you give them your login and password Obviously, there's a big security vulnerability here, you know giving out your credentials OAuth is the solution to this problem With OAuth, you give out access to the application without giving out your login and password to the party accessing the application So, you know, this comic is for lulls and all but don't try it I don't want you to take away that OAuth is some type of just another login and password It's really about authorizing permission for things Also, you know, OAuth isn't just for websites, you can use it for flash apps, mobile apps, desktop applications A really wide variety of things So Alright Tim, great, some techno hippie came up with some way open source way of connecting some websites together, you know Who's actually using this? Well, a lot of sites, big, small, we've got a photo bucket using it Netflix is using it for their API, Tripit Smugmug, there's some company, Goggle.com, I think they make sunglasses Yahoo, exclamation point Kind of an ugly color for a logo, but Anyways, you know, OAuth is the real deal There's a lot of people using this, a lot of big players, this is something that's going to be, you know Worthier time This is a screenshot actually of Yahoo's OAuth screen for authorizing the Flickr uploader I see a couple Macs out there. So, you know, if you've used the OSX Flickr uploader You've probably had to go through this process already and this is a really great example of a desktop app using OAuth to communicate with the web app So what isn't OAuth? OAuth is authorization and it's not authentication And you know, what's the difference? Well, authentication is about proving that somebody is who they say they are And you know, that's usually done with a login and password You could just as easily do it, you know, with fingerprints or biometric scanners It doesn't matter to OAuth OAuth, you know, that's not what it's about. It's not a login system OAuth is about authorization and authorization is about permission, permission to do things, you know Alice has permission to something and Bob does not Sad Bob You know, another example, OAuth is kind of like the hall pass you get in third grade, you know It means you have permission to be somewhere So one catch to this whole thing, what about fine-grained authorization? You know, what if you want people to have access to one part of an API but not another? The reality of it is most systems don't work this way. Most things are kind of all or nothing If you want then you could probably add some type of secondary authorization scheme on top of OAuth Or you could use, you could set up two APIs Let's say you wanted one for read access and one for read and write access You could just require applications to register separately for each version and you'd have that slightly more fine-grained access control And also, you know, this is an open standard. It's evolving right now OAuth is at 1.0. If there's a lot of demand for something like this, they might go ahead and add it in the future So if you're running a web service, you're probably going to want to integrate with another web service at some point And you know, if you have the choice to use OAuth or not, you might wonder, you know, why even use OAuth? Well, one reason is that people will trust you more You know Most websites out there are run by good people If a legit web service that's being used by a lot of people is asking you for your login and password You're probably safe giving it to them You know, these guys have way better things to do with their time than log into your email and do something malicious That being said, I don't personally like to give out my username and password and I rarely do This means I miss out on a few cool features, but I'd rather, you know, know that my information is secure Not giving out my login and password It minimizes the number of times that my username and password are stored next to each other in plain text somewhere You know, you probably know if your password is saved on a site for you to log into that site Hopefully it's stored in a one-way hash Which means that, you know, it's been encrypted so that it can never be decrypted and then when you log in it compares your encrypted version And if it matches you get in The difference for logging into another site is that if it's stored in the database Even if that database is encrypted already, it has to be decrypted at some point in order to go over to the other site And if it's being decrypted, it's in plain text and that's a vulnerability And honestly, it's not that it's necessarily the fault of the people running these systems. It's kind of a bad situation all around Linking systems together is one of the parts of the web, you know, that makes it possible to create amazing value with really little work Functionality of one system can get integrated into another. We don't have to reinvent the wheel. It's a better allocation of resources But, you know, annoyingly the only way to do it so far has been this stupid old model of, you know, sharing usernames and passwords And there hasn't been anything better until now So, you know, when I see a site using OAuth, I know that the people running it are highly likely to be on the up and up And it's very nicely helped sidestep the whole issue of trust You know, I'm sure that no one's going to do anything bad and by logging a password But if I don't even have to give it to them in the first place They can't use it Plus, if they're making a responsible decision to go with something like OAuth It's more likely that they're going to make responsible and well-informed decisions in other parts of their business. And, you know, I like responsible I trust responsible Another reason to use OAuth is that if your security does happen to get breached, your users will be safer You know, no one wants to get hacked, right? But every once in a while it does happen and I think a responsible company should inform its users if, you know There are security breaches But, you know, if you're in the unfortunate situation of having to admit to your users that you left your zipper down Isn't it nice to say that, isn't it nice to know you can at least say to them Well, you know, at least none of your data on remote systems was compromised And this is way better than having to tell everyone, look guys You've got to change all of your user names and passwords on all the other systems Instead with something like OAuth, you just let the remote system know and they can disable all your old access tokens in just one smooth move And everyone's safe And finally, it's ridiculously simple to use OAuth There are libraries available out there to make life easy and if you've set up OAuth to consume one API And you have to integrate another API Handling the OAuth part is going to be the easiest part of the whole process So now I've been talking about why use OAuth to consume APIs, but you know, what if you're Providing the API, why be an OAuth provider? First off, easier for you, you know It's a one-time setup and then everybody has a standard and secure way to get authorization to your service You can easily track which services are using your service as well as which users they're logging in as And it's a lot harder to do that if everyone's using the same set of credentials One other thing is that you know your users can manage which applications have access to their site and They can revoke access to any application at any time And because the access revocation happens at your own site It means that you know Company X can't have a backup copy sitting on the shelf somewhere if your username and password of all your know Of all the people on your system Also because the authors made some really good decisions If a remote service does get totally compromised and manages to post bad data to your system It's much easier to track and undo all the damage very quickly You can't really do this if everyone's using the same set of credentials to get access to your system Now I don't think anyone's actually done this yet But you could probably use OAuth and something like acts as a versioned to create some kind of secure Hybrid wiki system for you know your data So basically OAuth can make you look good as well as making the people you work with look good Another reason to provide OAuth is it's easy for developers to work with and you know what Steve Balmer says about developers You know developers developers developers It's almost suggested I sprayed myself down with a sweat bottle, but I'll spare you guys that That guy seriously So developers it is ridiculously easy to integrate OAuth into their projects Which means that you know it's more likely they're gonna work with your system Now like I said, I have a couple slides showing just how you know little code it takes to integrate this whole thing and it's not gonna be some long boring code demo because Honestly, there's not enough code for it to get very boring So, you know, you're working on an awesome project. That's gonna be totally popular, right? Well, if it's popular other people are gonna want to integrate with your system And the more people that integrate with you the more it cements you as a leader, you know good times all around Well, if this is the case don't make your users have to spread around their credentials to your service You know if company X has your users credentials and they get hacked You can easily get hacked as a follow-on and who looks bad when you get hacked, you know You do and your users do That's my favorite It's funny that I pick on Twitter because of this everyone loves picking on Twitter, but in this case, they're actually responding the right way Presumably as a result of you know all this recent security issues. They've opened up access to an OAuth beta for accessing Twitter And well, they opened up access They actually got flooded with requests for joining the beta within a few hours and actually had to shut it down as a result. I Wonder if they put up a fail whale when they got flooded with requests Okay Real quick about the fail whale if you like the fail whale Google for something called random whale It'll pop a fail whale back up every once in a while It's really easy to get to and you can still use Twitter and it's always really good for a laugh or two when The random whale pops up on top of a legitimate fail whale So anyways regarding the mailing list thing They have announced that any widely used Twitter apps are still going to be allowed to join the beta So hopefully we're going to get to see the the result of this sometime soon And also hopefully they don't start relying on the OAuth access as a way of you know generating money Which they keep talking about Access really should be available to everyone. It's better for everyone and regardless of their ability to pay for it So, you know another reason to provide OAuth is that you don't want to put your reputation on the back of dangerous URL comm You know and remember kids every time your users give out their credentials to your system to somebody else You're sleeping with all of the other websites that it's slept with Some of those websites might even run ASP.net And finally, you know you help build the understanding and less savvy users The usernames and passwords aren't things just to be handed out whenever some web form asks them to you know You're helping build a better internet and that makes everyone feel good. Oh Oh All right, so remember developers hard APIs users hard security OAuth equals hard So, you know, what if you're thinking hey, you know, yes, this secure authorization thing sounds like a pretty good idea I should make my own Well, you know don't isn't don't repeat yourself. We have a great authorization system right here It's an open standard and it's available to everybody There's no need to write another one, you know integrate OAuth and then spend your time doing something else Which hopefully involves a beach and maybe a drink with a tiny umbrella So let's start with code demo with the code stuff and we'll talk about how to access a remote system with OAuth Now if you're accessing the system that provides OAuth you are a OAuth consumer And like I said, these are based off of Pell's tutorials He and he wrote the gem and plug-in. So, you know, he knows his stuff inside out. So here's what it takes Now remember how I mentioned that the spec authors did some smart thinking Well, you know, one of the good parts of OAuth is that in order for someone to consume your API They have to register at your site. So if you're building a system to access somebody else's API You're gonna have to go register at their site This is almost always a painless process. It's really simple only a few pieces of information You're gonna need to give the name of your app so that when users are on the person's site The site knows what to call you your app You also need the main application URL, which is you know your domain calm the callback URL Which is something that's gonna get used as an endpoint in the process and then a support URL Which is I think a really clever thing to include right at this Because if there is any issues in the whole thing it gives users the ability to know where they can go to get some support The callback URL is actually I think a really smart thing because if someone uses your credentials to initiate an OAuth Transaction with the provider, they're always gonna get sent back to that callback URL It's not something that gets handed around in the process. So, you know, if someone uses your credentials The user is still gonna get sent back to your legitimate site makes things a little bit safer So once you've given the provider your information, they're gonna give you what you need to get into their system You're gonna get a consumer key a consumer secret and this is kind of like a login and password for their system You're not gonna need to type these by hand. So it's gonna be really long pseudo random jumble of characters You're also gonna get a few URLs the request token URL the access token URL and the author's authorization URL and Right now just know that these are a couple URLs you're going to use during the process. I will we'll cover this in a little bit All right. So, you know now you're registered for the system time to actually start doing some code Obviously everyone has different ways to organize their code So we're just going to cover the steps that are required in the process and you know It's up to you to actually integrate that into a model or a library or however you want So the first step pseudo gem install off easy Now like I said if you're using this to consume an OAuth API or an OAuth consumer So you need to require the consumer libraries So when your code is ready to do the action request You're going to set it up with a consumer key and the consumer secret that you got during that registration process And you're going to get back a consumer object From here you're going to need to get a OAuth request token. It's just a simple call like that It's going to go out to the remote service get a request token and give it to you at this point The request token is basically like a key without a lock And in the next step we're going to make it actually useful for something So you take the request token you're going to get the authorization URL out of it and then you redirect your users to the remote service from here the remote service is going to take over and authenticate that and authenticate them And remember, you know OAuth is about authorization and not authentication The remote service is going to handle proving the identity of the user by whatever means they feel necessary Whether it be cookie direct log in knock knock joke click the picture of the monkey, whatever After they finish the authentication, they're going to get redirected back to your system And at this point the request token will have been activated So and you know like I said with the request with the callback URL being stored in their system Good security measure. It makes it a little bit harder to tamper with the whole process Really what this is doing is it's putting security in the hands of the people who are running the API rather than some third party Because really if you think about it, you know if their database isn't secure, you know The whole thing is for nothing so by keeping the endpoint in their database It's just as safe as the rest of this as the rest of their system Okay, so at this point your users been sent back to request token has been authorized And this is going to be what you're going to use to get the actual access token Which is going to be how you make the calls back and forth So you just do this call you get the access token It's going to go out against the remote service and pull this data back The access token is its own object and it has a few methods built into it Which are going to make it really easy to do all the back and forth that you need For example, you have a get and you have post methods and these are going to work pretty much like regular, you know net HTTP requests so no hidden magic here and actually the response that you get is a standard net HTTP Ruby response object and you know from there on out you deal with it just as you normally would response body so on and so forth You know so overall really simple. There's that initial set of process, which is like 10 minutes worth of work There's a little bit of code which is just copy paste pretty much and you're on your way to consuming OAuth Protected APIs So, you know, this is some useful stuff, but you know, I bet you're sitting there thinking, you know Gee Tim, this is pretty cool stuff. I want to use OAuth to protect my API. How can I do that? Well, hypothetical audience member. I've got the answer in the next few slides If you allow access to your API, you're a OAuth provider and like I said being an OAuth provider is great One nice bonus is that because you're working with an open standard. It makes it really easy to build on top of For example rate limiting is something that lots of API lots of APIs want and it's really really easy to add using OAuth So again basing this off of Pell's tutorial and I'll include the links at the end Now there are a couple options out there for doing this whole thing. I like his gem for a couple reasons He includes a controller that will let your users manage their own request token or their own access tokens And like I said, you know, they can manage and revoke access tokens, you know all by themselves It's really easy really simple and very secure Also, the gem is set up by default to use HMAC SHA-1 encryption for all the transactions, which is a good thing It's secure by default And also you're going to get a set of before filters, which you can use to protect your actions with and these will integrate with some of the popular Authentication plugins which by the way is one of the catches to do this You are duty to be using an authentication plugin on your site acts as authenticated Restful authentication and restful open ID authentication will all work just fine So to get started if you hadn't already so you don't install OAuth From there you need to install the OAuth plugin which you can pull down off at the Google code site So we've got the code installed on the system time to actually start doing the integration Just run script generate OAuth provider, and it's going to do its magic and give you a bunch of controller a couple of models and also Some routes. I don't believe the generators go into install these routes automatically So you're just going to need to copy and paste them in As you can see, there's a few of them and they all are endpoints that are involved in the whole process You could change the routes throughout the names. I recommend not doing this It's you know, they're all names based under OAuth if you're not using OAuth you probably don't have anything called OAuth already and These are some of the defaults that'll just make it a little bit simpler for people to work with So since OAuth is going to allow a remote system to act like a user on your system You're going to need to add a few associations to your user model And then finally run the migrations that were created during the process restart your server and you're good to go Now from here, you've got the ability to protect individual actions or controllers in the same way Using OAuth in the same way that you do with your regular system You're probably used to like a current user object Representing the currently logged in user and you're going to get the same thing with OAuth So all your code is going to work just the same Now you can set whole controllers to be accessible via OAuth and login You can protect specific actions with OAuth and login or you can make certain things, you know, OAuth only And that's actually the end of integrating OAuth into a Rails project So this is a diagram of the whole flow of data representing an OAuth transaction And this whole process assumes that you've already gone to the provider site registered and that's all been taken care of Now when the process starts the OAuth consumer asks for that request, how can we talk about? And as part of this request the consumer key that you provided is sent along with a nonce A nonce is what is short for number used once And the reason nonces are involved is that it prevents replay attacks from being done You know obviously if the number has been used once it can't be used again In addition to this another important piece of data is the signature method OAuth transactions are encrypted and the signature method tells you what encryption method is being used Now like I said the gem that we just talked about uses HMAC SHA-1 by default There's also RSA SHA-1 and plaintext Plaintext doesn't sound like a very good encryption algorithm because it's not But actually the spec says if you're using plaintext it has to be of over an already encrypted communication protocol like HTTPS So the provider is going to respond to the request with a request token and a token secret And remember at this point the request token isn't valid yet The consumer is going to have to direct the user to the site where the authentication will happen At that point the user will get sent back and the request token will already have been marked in the provider system as valid So the next OAuth action that takes place is the consumer asking the provider for the access token And remember that this is what actually lets the post methods get called and lets data go back and forth The request token is going to get sent along with the consumer key, the signature, the time stamp of the transaction And as with all of the other steps in here there's a nonce going back and forth Every transaction is going to have a nonce And then the reply to the access request comes back, it's the access token and a token secret And that's the specific token that's going to be tied to your application ID And the particular user that authenticated your access And that's how you can keep track of who's doing what information transmission So you know like I said there's a few more steps and a few more pieces of data being passed back and forth Then were mentioned in the code and you know like I said that's one of the nice things You don't have to worry about this In this whole process there's actually seven transfers back and forth between the remote system and the consumer And each of these transactions requires another endpoint which is what all those different things were that we got earlier in the process But you know like I said it's really simple to do in code and especially considering the value that you're going to get out of this It's totally worth your time So that's you know OAuth in a nutshell, front to back, simple process There's a few steps thanks to the magic of RubyGems and it pretty much works out of the box But you know that's not all we can do with OAuth Just like with everything else there's a lot of customizations we can do A lot of them are really simple and you can get really good results out of this For example you know those keys, OAuth uses these really long strings of pseudo-random very hard to guess tokens And you know that's great because you don't have to type them and they're hard to guess so no one So it's less likely that someone's going to be able to hack into this whole process But you know imagine a situation where you did have to type them Maybe some device doesn't have a web browser or something like that but still has an internet connection You know maybe a cell phone, some type of set top device, digital photo albums, you know whatever it is If you can't get the authentication key to the device via the normal back and forth with the HTTP The only option you have is to type it in and it would suck to type these ridiculously long and random strings So you have a device with really limited inputs So the spec actually covers this and what they say is that if the system being accessed is intended to be accessed from a device like this The OAuth key should be generated in a way that makes it possible to put them in You know maybe compose it with simple words and numbers rather than just long garbage characters It makes it a little simple if you've got just a you know some type of joystick input You can do the you know contra up up down down left right kind of you know secret codes for getting access Whatever it is it's a clever idea on the part of the spec authors Okay so you know let's keep talking about the access tokens The access tokens can be set to expire on whatever schedule you want A month, six months a year, whatever you know it's up to you as the provider But you know think about going about it the other way with short life access tokens You know lots of systems do this hey let's log into your email account and check your address book and see if your friends are using our system You know how long could it possibly take to pull down an address book just a couple minutes right Well you know in the interest of only giving out permissions that you need to You could make OAuth send out only you know ten minute access tokens Which is more than enough time for the remote system to get in do its business get out and then they're blocked from ever doing it again This is a ridiculously simple change to make technically speaking But again it's a lot of value for the amount of effort that you're putting into it So you know you're the API provider and you're cool with people accessing your system You're not charging for the service And although you know most people won't abuse it It is the internet and you know sometimes you need a few restrictions You know good fences make good neighbors goes the same Well for an API this comes in the form of rate limiting You know set fair limits and then enforce them With an OAuth this is ridiculously simple So this tip comes courtesy of John Sampson of Zentact Zentact is implementing OAuth for their upcoming API that we're working on And he came up with this idea you know fair disclosure Cloudspace has worked with Zentact But that being said I think Zentact is a really cool system that you know is perfect for people to come to conferences and do networking things Strongly recommended to go check it out So you know enough of the shameless self promotion back to the rate limiting These nonces remember these things numbers used once Well if it's if it can only be used once it's got to be written down somewhere so that you can know if someone's using it again right Well there's a table that records all of these nonces And all you've got to do is make a migration that adds application ID to this table Modify the controller a little bit to store the model to store the application ID in the database So from here you've got the app ID you've got the number of nonce rows and you've got time stamps From here it's a trivial just count operation with the time frame and you know how many accesses someone has done over whatever time frame you specify It'd be very easy to add to the controller and say you know if count greater than my personal comfort level access revoked And you know this is a really great way of taking advantage of the fact that you're already storing this information anyways Which is one of the nice parts about doing it with OAuth Okay two for one I think I've shown some really compelling reasons to use OAuth just by itself You know it's good standalone and these are some good improvements But you know that you can double up here Plaxo and Google are working on a test project to combine OAuth and OpenID Right now it's just a test so that Plaxo members can invite new members via Gmail But here's the you know the idea is that you know we showed there's like seven steps back and forth in this whole process Obviously there's a lot going on back and forth and you know that takes up time and resources The idea with this project is that you know with OpenID also there's a lot of back and forth Why not combine the two? There's no way around the back and forth you have to get the data from point A to point B But if we combine the transactions into one set there's less back and forth, simpler for your users, faster for your users And I really hope that this works out for them They've published a draft of an extension to the OAuth spec And you can find that outline at the Google code site In my opinion anything that we as developers can do to make our own lives easier As well as making you know it better for the end user is a total win You know so OpenID and OAuth bringing people together So all that we've been talking about might be sounding a little bit like Facebook Connect The combination authorization and authentication thing that Google and Plax were working on Is almost going to serve the same purpose as Facebook Connect Kind of So what's the difference between the two? Well OpenID and OAuth work everywhere and Facebook Connect works on Facebook So you know unless you're already tied to Facebook for some reason I would put my energy towards OAuth first I'm not going to open source hippie out on you and demand that we all boycott Facebook I'm just saying that OpenID and OAuth are open specs that are going to be innovated on Going to be built on They're better for everyone, they're available to everyone And you know that's a good thing But you know on the other hand Facebook is a big market for some things And we can't pretend that Facebook Connect doesn't exist But you know in my opinion go with OAuth first and Facebook Connect second Alright so we're coming up to the end so you know get your questions ready There's a few more things Now I hope you enjoyed this I hope you're going to go home and try this out and actually implement OAuth on your site It's very cool and it's a solution we have to a problem that is here now But you know OAuth isn't all milk and honey and roads paved with gold The grass is not Willy Wonka edible but on the flip side no one's getting sucked up a tube of chocolate either So that being said there are a few criticisms that we need to talk about No fine grained access control I mentioned this earlier In my opinion it's not needed and it's kind of premature optimization of the spec Start with version one, make it simple, get the adoption out there for most use cases And then build on what people actually need And you know plus if you really need it add it on make the different APIs like I suggested Or you know if you're really serious submit an addition to the spec You know you don't have to be Google to come up with a good idea And if you can put together a nice tech document that describes a simple and backwards compatible way to make this whole thing work out You know you might find yourself becoming a spec author in the near future Okay So one complaint that I've heard about this whole thing is that it's scary for users You know one minute you're at one site the next minute you're on another Things are bright and moving quickly and maybe too intense for small children My personal response to this is that I don't think this is very valid You know really people are clicking from site A to site B all the time And moving from site to site is not scary you know And as far as it being a new process that people have to get used to You know the more people that do it the more people get used to it win And also really all you have to do is be responsible at your own service Before you redirect the user tell them you are about to be redirected You know put up a screenshot of the screen that they're about to be redirected to You know pretty pictures you know people love that stuff they will get it And especially considering the benefits that we get out of OAuth This is a really small hurdle to overcome So this is the last criticism and in my opinion it's actually the best one So you know you're a user you click through the whole process You go to the provider you type in your username and password you get redirected back And you have access and everything works and it's awesome right Well no Now rather than some third fourth party Hacking into this existing you know consumer provider relationship The whole thing that you just saw was a complete con There was no real provider site The site that you were trying to get access to just forwarded you to some phishing site With you know a really slick UI and stuff like that Fake URL the whole nine yard same way phishing works for everything else Your password your login password have been stolen So you know let's address this First off this is not a hack of a legit setup This is not a vulnerability between consumer and provider So really this is more criticism of OAuth the concept not any particular implementation And really you know people are always going to say oh they can spoof it about any kind of system like this So what can be done about this Well we have to do a good job branding our sites you know educate the users And if you're a provider make your authorization process as secure as possible You know one popular thing is showing an image that's not ordinarily visible to the public And if the user doesn't recognize you know maybe a picture of their own head Then they know that the thing is fraudulent Or you know do the whole thing over HTTPS And use the browsers built in UI to indicate a secure site You know you've got color changing address bars little pictures of padlocks and things like that And people have already been educated about these types of interfaces You know online banking everybody uses that And the banks do a pretty good job explaining to people HTTPS So you know this is something they're highly likely to be familiar with already You know like I said this criticism is kind of valid but it's really not very big So thank you Oauth isn't perfect nothing is but Oauth does make things a little bit harder to mess with And you know this isn't a really huge deal it's a valid concern we should be aware of it Is everyone aware of it? Good So to finish up these are the resources that I promised you If you want some more you can email me tim at cloudspace.com I will get you hooked up with whatever you want This is the one for how to become an Oauth provider There's the URL or just Google for the title of the document and you'll find it no problem Anyone need any time to write it down? Alright This is the one for being an Oauth consumer for developing Oauth clients in Ruby Notice it's not you know developing Oauth clients in Rails because it's Ruby You can use it for whatever you want You know you can use Oauth on Matt Williams' Bartuino project and you know control access to screwdrivers Which would be awesome A couple more links for you The first one is Oauth.net is the official site where you can find information about the spec Implementation details and the spec itself So the first one is a list of sites that are currently implementing Oauth If you are already an Oauth provider or if you're going to become one Go add yourself to the site It's good publicity, it's good page rank, you know It's definitely worth being on that list The next one is the Google documentation for their Oauth implementation If you really want to get into this go and read their docs There's a lot of things, it's very complimentary to the spec I think and it fills a lot of holes that I think the spec doesn't explain you know use cases of very well With Google you've got a really good explanation of use cases written by Google So you know hopefully they've thought it through and done a really good job with that I think they did One other thing if you're going to go home and check this out One thing that I'd recommend is have just you know a notepad next to you And write down all the terminology of all the different parts of the system That was something that I did when I was learning this and it really did help You know sort of keep things straight in my head a little bit easier You could do it without that but I'd rather save you guys a couple of minutes on that And make it easier for everybody Also if you really have a very very deep fundamental philosophical Oauth question Actually email the Oauth authors All of their email addresses are on top of the spec document which is this last link here And I hear they're all really cool about this Chris Messina is personally interested in you know getting adoption of Oauth up there So I imagine they'll be very helpful if you need anything from them Okay so we cover what is Oauth you know authentication not authentication What isn't Oauth it's not things like fine grained access control It's not a new login system for your site you know your users They come to your site to login they're going to use the same login form that they've been using All along no changes there Why use it it's awesome how to do it a couple lines of code really simple There's a few add-ons that other people thought of I'm sure you could come up with a few of your own It's a well-designed system it's you know there's tons of explanations of the whole system out there So if you're trying to look to you know add things on top of it it's going to be really easy to do And then the criticisms which like I said there's only a few that I've been able to find And they're not even really very valid we got some flicker image credits for all the people that share their photos Under a commercial non-commercial license appreciate you guys And then finally you know your turn what questions do you have You said that it required an authentication system on your part Is that what sort of a requirement is that I am not sure of the details of how they tie in together I just know that it probably has something to do with the way that the data is stored on the database for those And just the way he wrote his gem the models integrate much nicer Are you using something else on your site No we're thinking about doing that I'm just wondering if that is sort of just a responsibility or it's an actual code requirement According to his site those are the three by the way for the video the question was about using Restful authentication restful open ID authentication or acts as authenticated I believe it's some technical thing that the way his gem works that's what it integrates with Like I said it's on his site the guy knows his code so You know that being said they are some of the more popular ones out there So I think it'll cover most use cases Any other questions conference guy So is there are some good dots on the intersection between open ID and NOAA It seems like a scenario where you need a combination Are there things where you just need one piece or the other I haven't read through the spec Like I said they did publish it's you know it's a spec unto itself Again for the video at home you know what about the combination OAuth open ID thing It's a spec unto itself it's a you know formal addition to the spec So it does list out all the parts I believe basically what it comes down to is just in the hole back and forth It's just you know parameters that are stuck on via poster get or whatever And those whole things are encrypted you know using encryption things we talked about I believe they're just sticking a few more variables on some of the transactions back and forth So you know if you didn't want one part of the other you could I'm sure hack it up to You know leave those variables off of that particular part of the transaction But if you're really interested you should go check out the spec All these specs are actually really nice really clear very short which is good So you can get through them you know go home crack a beer and just start reading Good Cool Are there any other questions How many of you are actually thinking about you know going home and trying this out Buy a show of hands You're going to start implementing this in your site awesome I look forward to a whole bunch of new OAuth enabled applications coming out there Actually Robert Dempsey his expense application I know they just integrated OAuth For access for iPhone apps which is really cool Like I said Zentact there's an extension involved with that so if you have like browser extensions Which is another thing I'm really big on You know it's really easy to make OAuth A Firefox extension that consumes OAuth APIs so you know much more secure way of sharing data back and forth Alright you know so thank you for being such a great audience I hope everyone's been enjoying the conference so far We have the break coming up and then after that Will Limeweber is presenting on CouchDB And then UCF grad Dan Benjamin is going to be doing the keynote So thank you and enjoy