[MUSIC PLAYING]
TIM BRAY: Hello, there.
Happy Valentine's Day, everybody.
Welcome to Identity Hoodoo Voodoo on
Google Developers Live.
I'm Tim Bray.
I'm with the identity group here at Google.
And today with me, I have Naveen Agarwal, who's a tech
lead, manager, something important here in the group.
And he's been doing identity stuff for at least 100 years.
Naveen, give us some highlights.
NAVEEN AGARWAL: 100 years.
Well, if you include all the team members and so on,
definitely we've been doing this for 100 years.
So I've been at Google for two years.
Before that, roughly for nine years, I was managing the
identity team at Yahoo!, where we did OpenID launch, a lot of
things which were completely unknown, browser-based auth
and OAuth 1.0 extension, for example, which was Yahoo's
extension, which essentially became OAuth 2.0 for the
bearer flows, and so on.
On Google side, in the last two years, we've been making
things much, much easier, trying to integrate seamlessly
into different platforms and making the experience overall
much easier, and make things better for our users and allow
them to share and do what they want to do.
TIM BRAY: So increasingly, a lot of our users
are on mobile devices.
And that's what I want us to talk about today.
Mobile devices are super important, because in lots of
parts of the world, that's the only way onto the internet.
And even in this part of the world, an increasing
proportion of time is on mobile devices.
And passwords already suck.
And on mobile devices, the whole identity thing can be
very painful.
So what can we tell developers right now today?
NAVEEN AGARWAL: I think you're right.
We understand the identity issues are not that easy on
the mobile devices.
Almost all the flows which have been developed, they were
based on the browser.
They were assuming that the user was in a browser, the
bigger approval pages, and so on.
So we are trying to make the experience much, much better.
And we have actually been able to do a lot
on the Android side.
And you actually log in once.
And you don't really have to enter password a second time.
It's very rare, even, that you have to enter a password.
And we have found it's much easier to do all these,
because there are different security properties.
Users hold their phones next to them.
You're not sharing a phone a lot.
And so there are some nicer things which come with the
phone, so you can actually log the user.
And they have an expectation.
And they don't want to sign out.
In the desktop, people do sign out.
And again, the protocols were written assuming the browser.
So they do not really fall nicely into the Android and
the iOS operating systems.
But we have been making nicer changes.
And in Android, if you look at the OAuth 2.0 implementation
we have, it has nothing about OAuth 2.0.
Developer doesn't have to understand OAuth 2.0.
You just make a call to the [INAUDIBLE], say, give me a
token for these codes, and you get a token.
And you can use it.
TIM BRAY: So that's the good news.
But there's the other operating system.
And you mentioned it.
Many of our folks use Apples, use iPhones, and
iPads, and so on.
And we're still struggling a little bit harder on there.
In fact, I know people who have iOS devices complain at
me about, specifically, the Google apps and having to sign
in all the time.
So what are we doing about that?
NAVEEN AGARWAL: I think it is hard given that we--
it requires support from the operating system.
All of our apps require user to sign in, if you basically
have personalized experience.
And essentially, you have to enter ID and password each and
every app, which is really painful for a user.
And imagine if you are a two-factor user.
You have to enter ID, password, and an
OTP in every app.
TIM BRAY: And you should be a two-factor user.
If you're not, get on that.
Sorry, go on.
NAVEEN AGARWAL: Yes, I think that's a very good point.
There is no reason-- if you have anything valuable in your
account, any email coming in, you should actually sign up
for two-factor.
But given that, that's basically very hard.
We definitely want to have the single sign-on work fairly
easily between all the apps.
And we are working on that part.
So stayed tuned.
But I think that developers have even a harder time, even
on the iOS.
So we have been actually looking at some of the options
to make life easier for developers to get OAuth token,
given that on iOS, you don't have background apps.
You cannot talk to them in the background.
So it's much, much harder, basically, to do.
TIM BRAY: So have we got anything specific we can talk
about right now?
NAVEEN AGARWAL: Right.
So on the iOS, currently, there are a couple of options
if you want to get an OAuth token for Google APIs.
One, which is the Google+ SDK, and which is
actually very easy--
one of the best parts is if the user is signed into the
Google+ App, you ask for a token.
He's going to see an approval page, no password entry.
And user says yes, you get a code back.
And basically, it's a permanent code.
You can store it.
TIM BRAY: But lots of people don't have that app.
NAVEEN AGARWAL: Right.
But the good part is G+ SDK actually will default back to
the native browser, Safari browser.
And so if the app doesn't exist, it'll actually send the
user to the browser.
And again, if the user has to just sign in once into Google
in the browser, and they will see an approval page, and
they'll click on the approval page and basically go back to
the app, which is a very nice, smooth experience.
You could actually do this.
Now we have recently enabled--
you could actually make a call directly sent to the browser
without using the G+ SDK if there are certain things which
you may need which is not there through the G+ SDK.
TIM BRAY: So this has been working.
But we haven't been talking about it very much yet.
NAVEEN AGARWAL: Right.
We haven't talked about this.
But it is actually now live.
You could actually try it out.
And I do have an app if you want to see the experience
where you could actually send the user
to the Safari browser.
If they're signed into Google, they would just see an
approval page.
User says yes.
And they will get the code back to your app.
And you're signed in.
TIM BRAY: Should we be brave and try for a live demo?
NAVEEN AGARWAL: We could try.
We could give it a try and see how it works.
TIM BRAY: Switch over to the iPad there.
So I have an app here which actually
has signed into Google.
If I click on it, you can see it goes to the Safari.
I will sign into Safari.
I see an approval page.
And if I say allow access, smoothly it
goes back to the app.
And app has access to the data.
And it actually can fetch whatever it needs, basically.
AUDIENCE: Can you do that one more time?
We were not set yet.
NAVEEN AGARWAL: Sure
AUDIENCE: One second.
All right.
Do it again.
NAVEEN AGARWAL: So here we have the app, which basically
has signed into Google.
You click on Sign In.
It sends you back to the browser, where I'm signed into
the browser.
I see an approval page.
It's asking for some of the basic information about my
Google account.
I say Allow Access.
The code is sent back to the app.
And app can use that access token to
actually fetch the data.
So it's a pretty smooth experience,
actually, to make it work.
So you could--
I dropped the mic.
TIM BRAY: That happened last time I did this, too.
AUDIENCE: Leave it on.
NAVEEN AGARWAL: So the other options are-- which actually,
currently, people use--
are using embedded web view.
And there was no easier option for our developers on iOS.
And embedded web views work nicely from a user experience.
But actually, one of the biggest drawbacks is user has
to enter ID and password in each and every app, which is
really painful.
I hate entering passwords on my mobile devices, even though
it's easier to type them in.
But depending on how many characters and numbers I have,
it's very hard.
So generally, embedded view might look good.
People generally like them using our
GTM OAuth 2.0 library.
But they definitely are not the best experience from a
user point of view, because they have to keep entering the
ID and password again and again.
TIM BRAY: So after we decided to do this talk--
Naveen actually published a few slides on what you
actually have to do as an iOS developer to make this happen.
Could we switch to the Chromebook just for a sec
there, Dylan?
And they're linked from Naveen's Google+ page and my
Google+ page.
So if you just go to Google+ and type Tim Bray or Naveen
Agarwal, you'll find a link to this thing.
And there's this trick where you actually register a
callback URI where the scheme identifies your app by either
bundle or client ID.
NAVEEN AGARWAL: Right.
So in order to support the-- so essentially, what we did
not have a way from a browser to get back to the app.
And by the way, this works not just in Safari or iOS.
It works in other operating system for the native apps.
What we are supporting now is that we will redirect back.
If your app is a native app, or installed app, we would
redirect back to one of the custom URL which you provide.
Custom URL could be a bundle ID on iOS.
So for example, you can see com.example.myapp.
And you need to provide that bundle ID to us when you
register that client ID.
Or in cases on some operating system where you don't have
bundle ID or anything else, you could just use the reverse
of your client ID as the custom URL.
So you can see in this one, client ID is 1234-abc.apps.go
ogleusercontent.com.
We would basically select one of them.
You can pass that as a redirect URI in the call to
the browser.
And if all this matches out, we'll redirect
back after the approval.
TIM BRAY: So that's up there now.
We eventually will roll this out into the regular
documentation suite.
But it's there, and it's working.
And you're encouraged to go ahead and give it a try.
So let's go back to Android for a second, where
everything's built in and easy for us.
We've been working on basically
minimizing the approvals.
NAVEEN AGARWAL: Yes.
I think one of the things, when we started with OAuth, or
even with OpenID, we were very approval page trigger-happy,
what I would call it, basically, putting lots of
stuff on the approval pages, trying to make sure that user
is very well-aware of.
What it basically has created is that user may click on
approval page without even thinking about it, or they're
seeing the approval pages very often.
And they don't understand what's going on.
So we are trying to minimize the number of times we show
user approval pages, or where it's not really needed, and we
can actually infer that user is actually trying to do the
right thing.
And one of the things which we did recently on Android was
where the user is trying to get an ID token to log into
their own web server, essentially, if the user has
selected an email address from the account manager, then he
is saying yes.
I want to actually use this account to log in.
There is no approval page.
And we give out an ID token, which essentially gets you
access to an ID token and also their public Google profile
information to that user.
TIM BRAY: Basically, what we're trying to do is to ask
the user for permission only when it's reasonable and it's
worthy of their attention.
So if I'm using some developer's Android app, if I
also want to identify myself to their back end, I shouldn't
have to ask for permission again.
They should do that.
So we've been making some--
NAVEEN AGARWAL: So I think we-- just to also clarify, we
have also done this on the web.
So in certain flows, if you know the user's email address,
and if you pass that email address to an auth end point,
and if you are only requesting an email scope, we would
actually not show an approval page if the user is signed in.
And we'll send you back an ID token which you can verify
that the user is signed in.
So you could use that to actually verify
user's email address.
Without sending them an email, you could actually do that
fairly easily, because the user had entered the email
address on your side.
And you redirect back.
And so there are lots of good use cases you will see in the
future we may be enabling.
TIM BRAY: So identity on the internet is--
the internet's huge.
And the identity problem on the internet is huge.
It feels, sometimes, like we're facing this incredibly
tall mountain in the Himalayas.
But we are inching up.
And the idea is to keep people safe and secure and not pester
them all the time, because that's part of
security, as well.
So we're running a little bit long here.
Dylan, unless there's somebody online with a question, I
think we should maybe call it a day.
And we're good.
Fair enough.
So thanks for dropping in and listening.
And we'll be doing these on a regular basis, so come back
for more identity good news and nastiness, as well, on
Google Developers Live.
Thank you kindly.
NAVEEN AGARWAL: Thank you.
[MUSIC PLAYING]