You can listen to the podcast and read the show notes here.
Michael: Welcome back to the show. I'm here with Matt Gifford, and he's joining me from Cyprus which is hot and sunny as opposed to England where I am right now which is kind of a little dreary actually. I think I was a good move you made there Matt. And we're going to be talking about OAuth 2, and how you can use that do really amazing logins on your ColdFusion apps. And we'll look at how it works, what it is, how you can use it in ColdFusion. And we’ll ask him what his favorite rapper is; and I mean code rapper, not music rapper there.
And we’ll also look at some of the intricacies of registering your app with Facebook, and Twitter, and Google and some of the other providers you can use OAuth with. And so, if you haven't met Matt before, he is a cool guy. He used to run the user group for ColdFusion in England, and he's also presented a lot of different conferences. And his company ‘Monkey Works’ does mobile apps in ColdFusion development. And he's also written a book. What's your book Matt?
Matt: I've written a few books. The first one, I was object oriented programming in ColdFusion. I’ve written ‘Find Out Application Development’, and very quickly updated ‘Find Out For Application Development’. And a lot of magazine tutorials, and articles for UK, and [inaudible] [01:28] magazine as well.
Michael: Well, great! Was wonderful to have you on the show today.
Matt: Thank you very much for having me. It's a pleasure to be here.
Michael: Yeah, so for folks who haven't really come across OAuth 2, what the heck is it?
Matt: It is a possibly confusing based. Actually, it was developed to make like easier for developers so. Let's go with the prime example of a login, and if you're building a web application where you want to login, or creates an account. If you're building something from scratch, you have to worry about storing information, building the whole processes to take the form, and submission, validate it, send it back if it's false, lock them in, hash them, deal with all the password, and stuff.
OAuth kind of simplifies that a lot and you can delegate that whole back invalidation, and the user access to a different provider. [Inaudible] prime example, so you could just have a button on your site that sends OAuth to log in using my Facebook account, and they redirect you to Facebook, and you login using them. Or if you're already in, it were just pop up and say, do you want this part to use your details, and away you go, and you receive a minimal pay load compared to all of the other stuff you might have had to have done behind the scene if you were all on your own.
Michael: So yes, so that makes it easier for you as a developer, but it also makes it easier for your users because they don't have to remember yet another password, and user ID.
Matt: Absolutely, absolutely so it's not quite a worldwide single sign on solution. But yeah, people are the one place with [inaudible] [03:12] all the time, they have Google mail working all the time. Chances are most people have at least one of those three. And those are three of the biggest providers around, or at least two. So you can just log in using one of those services which means it's one password less that you have to remember, less spam that you have to remember.
So you don't have to deal with someone else sending you reminds, or email validation. You're already part of that system, so the apps that you want to log in based on just delegating to them and getting back, and mind a bit of information about you that you actually control. You're able to either prove it, or deny it. So you know what information that the application you’re logging into is requesting about you which is another massive benefit.
Michael: And I guess the fancy term for this is social login.
Matt: Yes, yeah everyone's a social guru in their own. At least, a few of those sites. So yeah, these are the social logins because they can then… the application if it has you logged in and say it is Facebook or Twitter they can then use… if you've given them permission to, they can then access your timeline, or post on your behalf. So, in some ways, it can benefit the site that you're logging in to. But again, it's only if you actually granted that access. It's embracing the social atmosphere in the cloud services that are out there already, and making life simpler for the consumer around the web application as well.
Michael: So, what kind… You mentioned Facebook and Twitter, what other people you know, what other providers can you log in through?
Matt: The big hitters, we have Facebook, Twitter, LinkedIn, and for the business geeks out there Microsoft services, or Microsoft Life I think it's called, GitHub, Bit bucket, Instagram, I believe Yahoo you have a variation. That's essentially most of the big sites that you use will have all of their variation most of them are up to [inaudible] [05:21] now. A few sites are still lagging behind [inaudible]. But yeah, the majority of the big hits as you can login using their services.
Michael: Cool! Now you mention OAuth 1 is that totally compatible with OAuth 2, or are they totally separate things or?
Matt: They’re separate entities, and OAuth 2 protocol document it's a very, very interesting read. I’ve been skimming it for years, still haven't finished it. It's kind of like the H.T.M.L. 5 spankings come from the changing never new additions being added. So you can give up after a while that you get so that where the key points are. But they are similar to an extent, but also drastically different in so far as the interviews, and the elegance of OAuth 2. I gave a talk on OAuth 1 about six or so years… Yes, six years ago I think it's [inaudible] when I just started diving into it. I've written the monkey tweets, ColdFusion rap of Twitter and that's what really got me interested in the whole OAuth environment and the protocol.
I’ve basically written this … of when they were using … sensation and it was a breeze too. You could just set up a very, very simple Twitter thing in your ColdFusion application, send your username, and password through in the HTTP request which we know is not safe. But from a developer’s point of view, it made it just crazily easy to do. And then it broke because they introduced OAuth 1. So, I had to very quickly learn how to implement that and what it was. And that took a weekend to get that actually up, and running, and working again. And at that time, they were already planning OAuth 2.
It was something that was in the distance but had a project line for it. OAuth 1 wanted to make life easier, and more secure. The emphasis really was on security. So, taking away the username and password fields being sent, and the headers all been sent in your form fields. You have to kind of do a signature dance really where you spoke to an app. The web application you were logging in to spoke to [let's use Twitter as the example], spoke to Twitter as the service provider. And said, “I’ve got Matt here wants to log in. These are his credentials. Can you sent me something back, so I can then ask him if he wants to proceed?”
And then, this multistep dance happened where there was a lot of back and forth which was secure, but very, very confusing. I'm actually confusing myself now talking about it. It was one of the policy had a lot of steps. But it got the end result the user they login, and use the services. OAuth 2 massively stripped that back where you have minimal steps needed to actually get the end result so you can actually send a submission off to twitter, they send you a code item back to the application. The application then sends that code back, gets another token, and you're pretty much in.
So from five or six steps down to two maybe three. It is a lot more secure. The user has the ability to revoke access at any time. I think with OAuth 1, but it seems to be a lot clearer with OAuth 2. And you have the added benefit of what we call scopes now in OAuth 2. So, I don't know if you Michael have logged into Facebook, or LinkedIn application using OAuth 2. But these application could pop up and say, “Matt [inaudible] [09:30] wants to look you in, or want to use your email address, your profile. It does not want to be able to post to your timeline.
Michael: right
Matt: So, you can very quickly see the intention of the application whether they just want your email address or whether they want to actually move your friend lists, and be able to post spam on your timeline without you knowing. So you can very quickly decline that, and revoke the application if it becomes too much as well. So, it's a lot easier for the developer to access with OAuth 2. The end user seems to have a lot more control over it. And that yeah, the amount of steps involved are drastically reduced.
Michael: Yeah, I know. These single sign on protocols can get pretty complicated so. But do you have to deal with that complication if you're using a wrapper for it or?
Matt: No, on the whole no. I’ve written a few of them now. I've just been adding to a new one after I've updated for OAuth 2 to make it much, much easier so I have a base compiling it and then it’s a very small plugin. So, if you want to use Facebook, they can just provide I think the token keys that you need. So as an engineer using those wrappers, you literally just give the bare minimum arguments that it required, and it will handle all the [inaudible] for you. So, ideally are one of the developers to be able to use the OAuth 2 protocol without having to actually worry how it works underneath. Just take this. It will work for you.
Michael: Great! Underneath it, how is it communicating? Is it sending X.M.L. or what is it do?
Matt: I don't believe any of them use X.M.L. anymore. Luckily, the X.M.L. payload’s a thing of the past. You have to have… it's very heavily header based, so you’re making H.T.T.P. post requests to submit some header information which is really the signature that you want to send, and the signature is a concatenation of the particular secret value on the token value. There are a number of different elements there. So, the user logging in, you will providing, you're still providing some account details. But not to the application you want to log into so you're providing them to Facebook for example that the website that you are using has to register themselves with Facebook or Twitter or Google and say this is my application, here is my URL.
I want to use it for these purposes and I just want to retrieve email address [inaudible] profound information and they get generated an API key, and a token value and it's those bits of information that are sent in the header. And so, the user doesn't really have to do much the web application will transmit those. Facebook will determine whether they are valid web applications sets out to receive it, and then submit the information back normally in a URL parameter. The coding application then knows how to deal with and finish that communication.
Michael: So, we'll talk a bit about how you register your app in a little bit. But if someone was thinking of doing this, what other alternatives are that's using OAuth 2? Is there… Are there any I mean?
Matt: There are, I haven't fully investigated all of them purely because the avenues I have taken have let me fully down the OAuth 2 path. And as I said, the big hit use them so I kind of start with those. And OAuth 1 is still out there it is still a viable option. Maybe not secure, not as easy, but it's still there. Open ID is another alternative. The Open ID foundation have been to provide one entry point as well. That seems to be quite large a while ago. I haven’t used it. And I certainly haven't investigated it for quite some times. So, I don't really want to say the way whether or not it's valid. And Mozilla had a single sign on solution as well. But again, I haven't really dived too far into that one. But there are a lot of alternatives out there. If you Google OAuth 2 alternatives, I'm sure you find. All the listeners or viewers will find some possibilities out there for them.
Michael: Well, and the obvious thing I'm sure most listeners are doing they don't do any of this. They just force their users to create yet another user ID, and password.
Matt: Yeah, if you can file that off to someone else, and you just receive a payload and store that small bit of information, then your life is much, much easier, and also you don't really. It helps to minimize any possible P.C.I. compliance issues as well because you're not storing passwords. You might store a… like an ID number that relates to a Facebook login, or Twitter number that relates to that particular login, but you're not storing necessarily unless you choose to. Put on email, passwords; you don't have to worry about encryptions or hashing, or any of that kind of stuff. So that’s one of the massive, massive benefits without filing off to somewhere else as well.
Michael: The other one I've come across is Sammui. I don't know if you've looked at that at all.
Matt: I don’t know.
Michael: Yeah, it's seem to involve a lot of sending X.M.L. back and forth, and you have to mess around with the key. And it was real picky about having things in a certain order in the packet, and…
Matt: yeah
Michael: Without telling you in the documentation that's the what you needed to have so.
Matt: yeah
Michael: I'm kind of curious whether Open Auth is easier to use.
Matt: I certainly remember fighting that fight with his XML pilots in the past. I'm glad that I've turned my back on that. I think the benefit of just having like a code value sent in the URL for you and then sending that back is so much easier than having to deal with XML structures and just building the structure to send before you even have to worry about the validation is just XML, yeah.
Michael: Just say no.
Matt: Well, they have its place, but no
Michael: Yeah, so if someone wanted to use this today from ColdFusion, what do they need to do? They download a wrapper?
Matt: Yeah, it depends what service you want to use. So the first thing you would want to do is actually register your application. So again, let's use Facebook as an example. They have their own developer consult just like Google do. They have their apps consult. Twitter have apps.twitter.com, Facebook have their developer portal. And essentially, would log in using your own Facebook account and you essentially have to register an application. Support that point, you really need to have your local web URL, your local development URL because you’re actually going to test it locally before you put it out to production. So you essentially create a new application with them and you provide a name, maybe a description, and they already have a bit of information about you because you've signed in using their services.
And you provide a call back URL which is a very, very important property. So the call back URL really is when you make a submission to Facebook and you are requesting some information, that is the URL that they know using your… based upon your client ID, and your secret value that you send in the header. They use that call back URL that you also send to validate you as well. So, if that doesn't match, then it won't return you. And that is the URL that they will send the user back to with a bit of information that you need. They have to provide the URL for them. Some other mind a bit information. Sometimes, you have to provide the scope which is basically a check box of items that you want to receive. Like the email address, the ability to mind all of the users information, or just the name.
And once that is done, they would generates the client ID for you which is basically the A.P.I. key, and a token secret value. And you take both of those, save them somewhere locally safe; not in the cloud [inaudible] [18:40]. And then you would go and find a Facebook wrapper. There are some out there already. I wrote one which I will send the links in at the end. There are also… if you check out forgebox.ao as well. There is a great wrapper on there, and a number of wrappers actually developed by one developer. I can't remember his name right now, and he wrote ColdBox modules for Twitter, for Facebook, for LinkedIn, for Google. They’re all based underlying schema. So they are very nice simple plugins. So once you've found your Facebook wrapper, you download it, install it.
And ideally, all you should then have to do is when you instantiate that component is required that API key and that token secret. And you might have to provide a couple of extras. But that is the bare minimum requirements, and then it should work. You might have to do a few method calls to allow the user to interact with it. But that is the maximum that you should really have to do because all of the rest of the OAuth 2 stuff is being built for you. So, once you register the app and have the A.P.I. key, the secret, you’re good to go. And you can essentially replicate that for Twitter, for LinkedIn, and for Google. They all have their differences. Some have very strict requirements.
I think Google has quite strict requirements on what you send in, what you request. They even recommend that you request certain bits of information just for added security, have to provide a bit looser on what you can send through. But they all follow very much the same protocol. So you will start to see when you look at each of them at the [inaudible] [20:36] of information that you have to send through and ultimately, what each one of them is going to send back to you. And they're very, very similar. So replication after that point hasn’t really become a problem.
Michael: And do these things they give you; the key, do they last forever? Or they last for a certain number of years or?
Matt: The A.P.I. key and the token secret last indefinitely as the application only you can go in. And if you fear that someone has obtained them, you can quickly revoke it or regenerate it. So you do have a lot of control over that. As a user, say I've logged into an application that is using my Twitter credentials. Most of these big provides will actually display a menu option for you probably in the settings panel somewhere. It says these are the applications using your log in. You granted access to. You can then peruse those.
They might be ones that you clearly remember and you still use these others that may have duped you into signing it or ones interest no on around anymore. So you can clearly identify those normally when you signed in and you can revoke access to them. So as soon as you’ve done that, basically, Twitter will kind of handle, and wipe out whatever key you've given to that end user, to that other application. So even if they try to make any requests on your behalf, it just won't work because those keys are gone. So there's a lot of control on either side now.
Michael: Great! I looked on forge box, was it Jeremy De Young who wrote that?
Matt: Thank you very much. I was actually using that this morning, and the name just didn’t stick in, sorry Jeremy.
Michael: No worries, so we'll put the link to that social Twitter login thing in forge box on the show notes.
Matt: Of course monkey tweets. If you're using Twitter, then obviously, monkey tweets is the one to go as well.
Michael: What a coincidence that's got the same beginning as your company name.
Matt: I know right.
Michael: And that’s spelt not with a Y, but with an H so.
Matt: Monkey with an H, just to add confusion.
Michael: Yes, why does it have an H?
Matt: I can never remember. Just ended up with an H, and we stuck with it. So that is the one [crosstalk] [23:05].
Michael: Well, the H is underneath the Y on a quadi keyboard, so maybe you just typed it that way you know.
Matt: It was a late night the think just slipped. The company branding came from there.
Michael: So monkey tweet is the wrapper you wrote for Twitter that uses OAuth 2.
Matt: Yeah, that was the first one that used the basic authentication and then very quickly have to ramp up to OAuth 1, and then to OAuth 2. But a lot of time, a lot of time, and a lot of coffee went into that. That one [inaudible] very, very proud of that, and it seems to be used by a lot of people, and a lot of Cold Fusion apps are using it actively which is great. So, it's the open source free, and pool requests are welcome. Other Twitter wrappers are also available.
Michael: Great! So, just so we're clear, what exact does OAuth 2 cost? You have to pay for any of these registrations, or the code, or?
Matt: No, absolutely free. It is all free. And there is a small amount of time setting it up. So going into app store twitter.com, or the Facebook console, or the Google console. You have to define, you have to declare, and register your application. It can get a little bit tedious. Google's console isn’t the easiest to navigate at the best of times even if you’re following the tutorial which really points out which links to press because they seem to update their U.I. as well. So, if you don’t have a local development environment, you have to set one up for that because the call back URL has to match the URL that you are using locally. If you then have a staging environment, and obviously a production environment, you have to set up one for each of those as well.
If you then have an application that allows OAuth 2 through Facebook, Twitter, LinkedIn, it can grow exponentially. So, there is a bit of time in setting those up, but once they’re done, you have a lot of security on there and you know that they're sorted. And if you're using something like ColdBox where you can clearly define if I'm in a development environment then use these in your config, then it becomes fairly easy to manage from the code point of view. The providers, the service providers don't charge you; at least the big ones don’t. If you cross any that do try and charge you, don't use them. I think the benefit for them is that they have people using their services. It means that they're going to stay as a relevant service because they clearly have the data. So, there shouldn't be any monetary involvement, and it's all free.
Michael: That’s great! Yeah, I imagine it does kind a lock users in because even if they wanted to delete their Twitter account, they still need to keep it just to be able to log into the things they used it to associate with.
Matt: Yeah, I mean there are ways to an application working at the moment has social logins through the three big hitters. But also the ability to create your own custom login, and through the service as well. As I say, I’ve login using Twitter, I can then add the Facebook, or the Google mail. So, if I accidentally click on one of the wrong social logins, I’ve already pre-approved them to that particular account. Or likewise, if I create a custom account, then I choose I want to add one of my socials, you can do that as well. So you can still tie them together. Or see if you just want to keep it social, then just use the social logins, then they're all done for you.
Michael: So, anything else about OAuth 2 that our listeners should know?
Matt: It is a lot of fun. It is confusing. I aim… I jerk my prime goal at the C.F. Camp session. It’s going [inaudible] [27:13] through it. Again in a lot more detail actually showing some code samples, showing clearly in slides form, steps involved originally in OAuth 1, and now in OAuth 2. So, you can see how much easier it is. And essentially, I want the people to leave C.F. Camp session with a much, much clearer understanding of what OAuth 2 is. To not be frightened of it. And if they wanted to, to actually be able to create not only web apps that consume services like Facebook or Twitter. But maybe actually roll their own service, so that they can become the service provider. If their application is big enough, and they can actually be sending out user data to others instead.
Michael: Sounds exciting, so we'll talk a little bit more about C.F. Camp in a moment. But tell me about ColdFusion in Cyprus because that's where you relocated to from U.K. a few years back.
Matt: Yeah, absolutely. One of the first things I did when we were looking to move. I was quick to Google the states of development environment over here. Luckily, there are a lot of development houses. And those… I think there are two fairly close to me within ten minutes each way that are very heavy ColdFusion houses. I think one of them certainly uses ColdBox in the ColdBox suite. There does seem to be a thriving ColdFusion community. They’re quiet. The web over here as I've found doesn't seem to have taken as much hold recently.
So a lot of the current trends don't seem to have made it over here yet. But there are very, very heavy web houses I mean that are using it. One of the big companies over here is quite a large name in prototyping, and applications, so I was quite happy. I didn't realize they were in Cyprus until I moved here, and they have ColdFusion behind the scenes as well I believe. There doesn't yet appear to be a ColdFusion user group though. So if there's time, and coffee available, then I might look into actually getting something set up.
Michael: Well that sounds exciting for all of C.F. developers in Cyprus, Mark. I encourage them to contact you and offer coffee.
Matt: Yeah please. They’re very much welcome.
Michael: So, let's turn to why you're proud to use ColdFusion, Matt.
Matt: It's just an awesome language and it was the language that I … If we forget my minor stint with P.H.P. when I very first started development – which I think everyone did to an extent. ColdFusion just… it's an amazing language. Is the first one that really took hold of me, and I was able to understand. I think something is stupidly simple as the C.F. [inaudible] tag when I first started was a mind blowing experience because you could instantly see visually using color what the information was. It’s… I think it’s a brilliant language. I know that rapid application development term gets bandied around a lot. But it's still very, very prevalent. I use other languages. I’ve dive into node, I dive into JavaScript. I played with Ruby, I played with Python.
And they're all great for particular reasons. If you find a language that suits a task, use it. But I inevitably find myself coming back to ColdFusion because it does the job, and the language enhancement recently have been fantastic. If you look at the Lucee engine as well. I think it's opened up the gateway to a lot of ColdFusion developers, or CFML developers. It's a very, very easy language to pick up. The community is one of the best still around. I think the ColdFusion community is amazing; always has been. Made a lot of very, very good friends through that community, and it's kept me employed for quite some time. So, Cold Fusion is a fantastic language. Plenty of people out there to help you. We want to see it continue to succeed because it is succeeding. It's just a pretty language, so pick it up and use it if you haven't already.
Michael: Great! So, I mean that does come to you know, sometimes you read stuff about the ColdFusion is dying, and I think the opposite is true. It's become more alive. But the question I have for you is what would it take to make ColdFusion even more alive this year?
Matt: That is a very, very good question. I used to have the wish lists of I would love it to have a repo; a command language repo tour. I would love it to have a package management tool. Basically, it might not have 100 percent faithful answers to those, but we have them now. You know we have the CommandBox which is just amazing. We have ForgeBox which is our package manager to an extent. As long as people are contributing to the forges, and the packages. So, my wish lists items have been answered. I would just like to continue to see the language evolve. I would like to see it enhanced, and stay current really. I know that the engineering teams they have a particular project cycle, and a lot can change in that particular cycle. So your idea is that they had…
They might release on fortune by that time may then kind of be invalid in web terms, and usage. And I know that they’ve also very quickly kind of flip things around and introduce some amazing stuff. Like the A.P.I. management tools that went in the last few releases have been very, very welcome. They were long overdue I think. But the power that I have underneath to control your A.P.I., and kind of manage them, and dig in to the logs and really filter down the security. So, we have a lot now. For it to continue, I would just like to see open source contributions I suppose. If we can keep the package management libraries populated with valid ColdFusion packages, keep the communications going, keep the chats going keep the blog posts going, keep podcasts and bidcasts going. As long as we keep the buzz going, then I think it will continue to strife.
Michael: Great! So, what are you looking forward to at C.F. Camp in a few weeks?
Matt: Beer, lots and lots of German beer. That is true, but also the schedule. It's sold out which is amazing. I have no doubt it would sell out, but as it's the only European C.F. conference now. It's amazing that people are flocking to there. And the schedule this year is insane. Luckily, I'm only giving one talk, so I can easily pop into the other tracks. But it's getting to that point now where I want to clean myself because there's something good in this track.
And I'm primarily looking forward to actually catching up with a lot of friends, and colleagues who I haven't seen for a while. So conferences are always an amazing place to do that; especially the C.F. conferences. I’ve said it Scotch. I’ve said it about C.F. Camp before. It's kind of like a family reuniting once a year. To sit down, learn new stuff, catch up, and just kind of be together which I know sounds a bit corny, but…
Michael: I think it's important. You know you're working on your own, then it helps to see other people once in a while that share the same interests.
Matt: absolutely
Michel: And talk about what's going on.
Matt: And it's going to catching up a lot of people, and there's a lot of great content out there. I have to schedule a finale. But I'm very big in to automation and I think the last few years have spent investigating, and helping other companies automate their processes, and their work flows and kind of streamlining how they do things. I love automation which is why I'm looking forward to the bit bucket pipelines chat. I’ve started doing stuff on that, but I would love to learn more about that as well.
The internet of things, I'm aware of it. I've played with bits, but I'd still like to know how it can help me in my day to day life. I was once a kind of push a button on my app, and everything does [laughing] [36:09]. But there are just some really amazing talks out there. Some interesting things that I wouldn't have considered, and a lot of topics that I thought I had a grasp on, but after kind of digging into the description of sessions I’ll like to go into as well, and tighten up the skills on that. So, it's going to be a fun couple of days I think.
Michael: Great, exciting! So, if people want to find you online Matt, what's the best ways to do that?
Matt: Probably the best way is on Twitter @coldfumonkeh; C O L D F U M O N K E H. Always a monkey with an H, or www.monkehworks.com.
Michael: Fabulous! Well, thanks so much for being on the C.F. alive podcast.
Matt: Thank you for having me. It's been a pleasure.
