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