Placeholder Image

字幕列表 影片播放

  • RYAN BOYD: Hello, everyone.

  • I hope you're all here for the OAuth 2 session.

  • How's your day been going thus far?

  • AUDIENCE: [INTERPOSING VOICES].

  • RYAN BOYD: Good, good, awesome.

  • My name is Ryan Boyd, and I am a developer

  • advocate here at Google.

  • OAuth 2 isn't really my day job.

  • It's just a passion of mine.

  • Normally, by the day, I'm working on our cloud data

  • services like Google BigQuery, but OAuth 2 has been a passion

  • of mine since I started in Google at about 2006.

  • I was working on our proprietary authorization

  • protocols, AuthSub and ClientLogin, and I realized

  • how painful doing authorization for our APIs was

  • for developers.

  • And frankly, I think most developers spend about 80% of

  • their time dealing with authorization, and then the

  • other 20% of the time dealing with the actual APIs that they

  • were using, and that's kind of sad.

  • And it was especially problematic because, back

  • then, there were these proprietary protocols across

  • many different API providers, so if you learned how to

  • interact with Google's APIs using ClientLogin or AuthSub,

  • and you went over to Yahoo, you might have to use BBAuth.

  • You went to other providers, you have to use other

  • protocols, and this is really painful.

  • So I'm super happy that we've standardized on OAuth for

  • authorization.

  • We had OAuth 1, and that was still a little bit of painful

  • for developers to use.

  • At least, it was standard across many providers, and now

  • we're at OAuth 2.

  • The draft is nearly complete, any day now, I think.

  • And with OAuth 2, things got a lot easier for developers, and

  • we'll show you how it works.

  • OAuth 2 is such a passion of mine that I actually recently

  • released a book, a few months ago, with O'Reilly, talking

  • about OAuth 2.

  • It's a very short book, but gives you a good introduction

  • in about '90 pages, I believe.

  • So in order to understand OAuth, we first need to

  • understand a variety of different terms.

  • I went sailing last weekend, sailing school, and sailing is

  • all about terminology.

  • There's way too many terms even for me to remember.

  • Hopefully, OAuth will be a little bit better than that,

  • but there are various terms.

  • So we're going to introduce a couple terms up front here,

  • and then throughout the talk, we'll give you some additional

  • terms that are little bit less important, but are nonetheless

  • things that are essential to understand OAuth.

  • So the first term is authorization.

  • Sorry, authentication.

  • See, even I'm mixing these two up.

  • All right, pause here a second.

  • Authentication.

  • Authentication is about verifying the identity of a

  • user, knowing the user is who they say they are.

  • When you go and visit a website, and it asks you to

  • login, you type a user name and password, that website

  • verifies that you've typed the right password for that

  • account, and thus has authenticated you.

  • It's validated your identity.

  • But after it authenticates you, it needs to figure out

  • what resources you should have access to, and that's what

  • authorization is all about, making sure that you have

  • access to your data and only your data, or the very least

  • only appropriate data.

  • So if you went and logged into your email account, and you

  • had access to your colleague Tom's email, this

  • would be a bad thing.

  • So that's what authorization is all about, making sure that

  • you have access to only the right information.

  • Questions for you.

  • How many of you ever shared a password with an application,

  • a third party app, so it can access your data on something

  • like Google or Twitter or Facebook?

  • Raise your hands.

  • All right, some of you are just being shy here, because

  • I'm pretty sure everyone in this audience has done that at

  • some point in time, and this is obviously very bad for the

  • security of you.

  • And it's also very bad for the security of users as, after

  • all, you guys are developers.

  • You have plenty of users.

  • You should never be asking them for their passwords for

  • any of the major account holders.

  • So you have an opportunity.

  • You have an opportunity, as developers, to eliminate the

  • need for users to reveal the passwords to your application.

  • At the same time, you have an opportunity to restrict the

  • level of data available to your application to only what

  • your application needs in order to make a good

  • experience for your users.

  • And then you have an opportunity to allow the users

  • to revoke access to your app when your application no

  • longer needs access to their data.

  • This is your opportunity, but it's important to understand.

  • I believe that you have an obligation to your users, an

  • obligation to help keep your users safe.

  • And so you have an opportunity, but also a

  • responsibility here.

  • A few more questions for you.

  • Sorry, that was what OAuth 2 for

  • authorization is all about.

  • Now, we'll get into a few more questions.

  • Do you use the same user name and password

  • for multiple sites?

  • How many of you do that?

  • Tell you a little story here.

  • Of course, everyone does this.

  • I think it was like a week or two ago when some major

  • website, which I won't name, managed to get a lot of their

  • passwords leaked out onto the web.

  • And I didn't know about this, and I looked over at one of my

  • colleagues, and he was looking really sad.

  • And I'm like, Sean, why are you looking really sad today?

  • And he told me that now that his password was leaked out

  • there on the web, he has to go change his password, not only

  • on this site, but on dozens of other sites around the web,

  • and he didn't even know what those sites were.

  • So he was basically thinking, you know what, I had some free

  • time this evening.

  • No longer do I have any free time that evening, or maybe

  • even the next couple days.

  • So he was really sad about this, and you don't want to be

  • in the position of being sad.

  • And as developers, you don't want to make your users sad,

  • or have a risk of making your users sad.

  • Another question.

  • How many keystrokes do you type when you sign up for a

  • new account?

  • Call out some answers.

  • AUDIENCE: [INAUDIBLE].

  • RYAN BOYD: All right, all over the board.

  • Some of you have much longer passwords

  • than others, I guess.

  • I think I type about 50 characters.

  • I have a relatively short name even if I

  • do use longer passwords.

  • 50+ characters.

  • My first name, my last name, my email address, password

  • once, password confirm.

  • That's a lot of characters to type when you

  • sign up for new account.

  • What if you could drop that down into two mouse clicks

  • instead of 50 plus characters typed on the keyboard?

  • So again, you have some opportunities.

  • You have an opportunity to minimize the number of

  • passwords your users need to remember.

  • You an opportunity to discourage reuse of passwords.

  • And then you have an opportunity to optimize the

  • sign up flows for your application to get users on

  • board faster.

  • If you get users on board faster in your application,

  • then you get more and more users, and hopefully, you

  • become wealthy with the next IPO.

  • And this is what OAuth 2.0 for login is about.

  • And I use that term because that's the term we use in our

  • documentation.

  • Externally, you'll see this as OpenID Connect or OAuth 2 for

  • Authentication.

  • All sorts of different terms, but they all

  • mean the same thing.

  • So our agenda, we talked about some terminology.

  • Next we're going to go into authorization and go through

  • how you do authorization in a variety of different

  • environments, whether you're in a pure JavaScript

  • environment on the browser, or whether you're doing a

  • server-side environment with server-side code, or whether

  • you're doing a mobile environment, or even some

  • newer things with service accounts.

  • And then we're going to get into authentication, and

  • lastly, end up with a set of resources that will hopefully

  • be very valuable to you, including a link to the slides

  • so you don't need to be furiously taking notes.

  • All right, so OAuth 2 for Authorization.

  • Google has 35+ APIs which are enabled for OAuth 2

  • authorization.

  • Now, I say 35+.

  • I've had these slides for a bit.

  • I tried to count this morning.

  • There is probably many more than this, but at least 35

  • APIs that Google has that you can use OAuth 2 to get

  • authorization for, and this is everything from Calendar and

  • Contacts to things like YouTube and Google+.

  • All the Google APIs, when they require authorization,

  • support OAuth 2.

  • And not only do we have 35 APIs at Google, there are

  • hundreds of other APIs around the web, which use OAuth for

  • authorization.

  • Many of them are still an OAuth 1, but I'm sure they'll

  • be upgrading soon to OAuth 2.

  • Now, your goal when working with OAuth is to get access to

  • a user's data in one of these APIs.

  • In order to accomplish that goal, you need to get a token.

  • This is what a token looks like.

  • Well, not really, but this is a image to

  • represent an access token.

  • OAuth 2 works off the concept of access tokens, and all the

  • various OAuth flows that we're going to show you here today,

  • your goal is to acquire one of these access tokens.

  • And this access token if then used to access an API on

  • behalf the user.

  • So in each of the flows, we're going to show you how to get

  • an access token.

  • And then a little bit later in the presentation, we're going

  • to actually show you how to use that access token to

  • access the API, but trust me, once you have this access

  • token, you're all set.

  • All right, so to get started, the first thing that you need

  • to do to get started with OAuth is to register your

  • application.

  • You can visit the Google APIs console, and you can register

  • your application, and this will give you all the

  • information that you need to get started with OAuth, in

  • particular ClientID and also some other information.

  • So you can access that now on the new developers.google.com

  • site, developers.goggle.com/console,

  • and you can register your app.

  • So let's get into it.

  • Let's get to the pure JavaScript flow.

  • If you're developing client-side applications that

  • require only the browser, how many of you work mostly in

  • JavaScript?

  • OK, handful of you.

  • For those people that like the server-side code, we're going

  • to come up with some other things here later.

  • But the most simplistic flow is this pure JavaScript flow,

  • and it works something like this.

  • I'm going to go through a diagram here, and then I'm

  • going to go into the actual code in one

  • of our client libraries.

  • And then I assume, because you guys are in a session on OAuth

  • 2, that you want to know how it works underneath the cover,

  • so I'm going to go into the raw protocol as well.

  • So the first thing that we have here, and it's a little

  • bit small, but we have this fake app called Taskman, and

  • Taskman displays your tasks from your Google Tasks.

  • And Taskman says to the user we need access to your Google

  • Tasks and gives you a button to click on and say go to

  • Google to grant authorization.

  • Pops open a window that looks something like this, where

  • Google says that Taskman is requesting access to your

  • Google Tasks, and you're given the option to

  • allow it or deny it.

  • If you allow it, it's going to redirect you back to the

  • Taskman application.

  • And you're going to notice here, at the top right, we

  • have an access token, and this