1 of 30

^™

2 of 30

The Cutting Edge: Standards at work in Google's mobile focused future

Eric Sachs, Google, Director of Product Management, Identity

Pam Dingle, Senior Technical Architect, Ping Identity

^™

3 of 30

^™

4 of 30

^™

5 of 30

^™

As one example of a UX improvement, lets take an Enterprise use-case. Many companies rely on Google as a SaaS provider for our mail or docs service. Some of those companies run their own IDP to control logins to Google.
In the past, many such employees saw our older email+password login page, and would mistakenly type their corporate password into Google’s login page. Now that confusion goes away. Once they type their email, we simply redirect to their IDP.
On the desktop, they are usually already logged into the corporate IDP, and so without any additional interaction, in particular no typing of a password, the user is logged into their corporate mail or docs hosted by Google’s SaaS offering.
Unfortunately during phone setup they are not yet logged into their SAML IDP. So when they are redirected to it, they have to type their email again on the SAML login page. But OpenIDConnect defines a way to send the email identifier hint, so in the future we want to add OpenIDConnect RP support to GoogleApps to leverage that better UX with companies (or cloud IDP services like PingOne) that support it

6 of 30

^™

Of course, we all know passwords alone are not good enough, so Google has its 2-step-verification.
Unfortunately hackers are getting more sophisticated and now phish for OTP & password. We released a whitepaper last Fall showing that in targeted attacks, the bad guys have now learned to phish for an OTP nearly as easily as phishing for a password. That is pretty darn scary.
Some multi-factor flows have now switched to mobile remote login approval flows like this one that provide more information about the login request. It certainly improves usability since the user doesn’t need to type codes. It also provides some additional protection against the bad-guys by giving more information about the request. But at the end of the day, it is still susceptible to targeted phishing.
So how do we prevent phishing?

7 of 30

^™

FIDO is the industry work group where we are primarily focused on phishing proof authentication.
Many of you may know Google supports USB Security Key’s that support FIDO standards as a way to login to Chrome on desktops without worrying about phishing. Recently we announced the ability for our Enterprise customers to require that their employees use such a device on desktops.
Unfortunately you can’t plug those keys into mobile phones.
Fortunately the FIDO community is already work on standards for NFC & Bluetooth in addition to USB. With the latest version of Android, Google launched the ability for users to sign into a new phone by just tapping it with their old Android phone. We are also starting to test the ability to use dedicated Security Keys that support both NFC.
We’re making it possible for a growing set of Enterprises to eliminate phishing. We will continue to work on standards so this support can be expanded to other browsers and other operating systems.

8 of 30

We sent a verification code to (415) 114-0090

(555) 867-5309

Enter Google Account PIN

Forgot PIN?

Finding your Google �Account with MobileCo

^™

While we believe Enterprises can start to deploy this anti-phishing technology today, things get trickier in the consumer space.
For example, what if you lose your phone? Obviously you can’t use your lost phone to setup your new phone. And you might not have purchased a separate NFC enabled SecurityKey.
You might think we could just send an SMS message to the new phone. Unfortunately, as we noted earlier, bad guys have learned how to phish users for BOTH passwords and OTPs. So what they can do is start a Google login flow on a phone they control and enter the phish’ed user’s email and password. Google will then send an SMS which will go to the real user’s phone. But if the bad guy phish’s them for that OTP code, then the bad guy can enter it into the phone they control. And at that point they have broken into the account.
So the problem is Google can’t get proof of where the SMS ends up. The OpenIDFoundation’s MODRNA Workgroup is working to define standards that enable mobile operators to act as identity providers with cryptographic assertions, as opposed to OTPs that can be phished.
Google is starting to work with carriers who are interested in providing this security to their customers. For the growing set of “mobile-only” users around the world, this technique may be enough in the future to eliminate phishing of their accounts

9 of 30

^™

Now another area of standards work to eliminate passwords is with APIs.
For example API access tp IMAP for mail, or even a company’s proprietary APIs like the API’s offered by Google’s Youtube division.
Google has not only removed the password field from our login page, we also removed the password option from all our APIs. It took years to make this change because we had to get all the major 3rd party clients to make the switch to using the OAuth standard for API access. Even major email clients like Apple mail clients now use OAuth to talk to Google APIs. And in those OAuth flows, we can then leverage other improvements like 2-step verification, risk-based authentication, the identifier first technique I showed, and it is a prerequisite for Security Key support on those platforms.

10 of 30

E

Sign in & registration on mobile is too painful

^™

11 of 30

Save Eventbrite password securely with Smart Lock?

^™

At Google I/O we announced SmartLock for passwords to dramatically reduce the user pain
Instead of making them type all that info, when they click a SignIn button...
The OS shows a list of the emails they most frequently use because the app invokes the SmartLock Account Chooser.
The user simply chooses an account, and the app now has that email, name, & photo.
You may have noticed that Google’s own apps, like Youtube on iOS & Android, already use a similar user experience.
This user experience is based off the OIDF’s Account Chooser working group. Web apps can already get this experience today using accountchooser.com. We are just bringing that to Android apps.
If the site has never seen that email, the user could still create a password. However after they submit the form, SmartLock will ask if they want to save it so they can be auto signed in the next time.
The feature doesn’t yet support super advanced features like auto-generated-passwords, custom-passphrases, or enterprise password mgmt. Our goal here is to focus on common users first and get their feedback before we evolve the feature

12 of 30

mlaaker@gmail.com

^™

13 of 30

Don’t overthink

^™

14 of 30

^™

15 of 30

Registered

Not registered

^™

16 of 30

returning user

with password?

YOUR �APP

eric@gmail.com

Choose an account

Eric Sachs

eric@playthesachs.biz

Eric Sachs

esachs@google.com

Eric Sachs

eric@gmail.com

CANCEL

Select authentication method

Input existing password

Authentication at Identity Provider

new user?

returning federated �login user?

^™

...the app just needs to have the user type their email (or use an account chooser in their browser or Android). The app can then figure out whether to send them to an IDP, or a password entry screen, or ask them to register a new account.
If an account chooser is used, and the person previously registered with an identity provider, i.e., the 3rd option, then a single click on that entry will log them in.
The experience on Android can be even better. The app could have previously used the new SmartLock for Passwords API to save the user’s preferred email (and optionally password). In that case, the AccountChooser doesn’t even need to be shown, and both 2nd & 3rd options here then require ZERO CLICKS.
That 0-click process scales to even a SaaS provider supporting thousands of IDPs.

17 of 30

New UX, New Signals - backed by Standards

You can have the same UX as Google
http://accountchooser.com

Simple Login Hints protected by consent, standards
Overseen by OpenID Foundation http://ac.openid.net

Two added features

Identifier-first form
Protocol support for OpenID Connect login_hints

Cast:

The IDP: Integral Curve
The RP: Hipstabank
The User: Alice

Try it:

http://hipstabank.com/business demonstrates Federated Flows

^™

Video Notes:

Integral Curve is one of the biggest Corporate customers of Hipstabank Business Services. When Alice first visits Hipstabank, she has a pretty good experience, because she is prompted for her email at Hipstabank, and hipstabank passes it back to her IDP, where she does not have to type it again - in fact, she is put through an identifier first flow at her IDP, because Hipstabank sends an OpenID Connect Request with Alice’s email as a login_hint. This login hint represents COLLABORATION -- a signal sent prior to authentication, from RP to IDP

Once Alice successfully authenticates to Hipstabank, she is prompted to consent to storing her email at AccountChooser.com. If she consents, Her Email, her IDP, a photo and a Display Name are stored.

The next time she comes in, she types nothing except her password. If she’d been already logged in, SSO would have been seamless, and she wouldn’t have typed anything at all.

18 of 30

What you Saw in the Demo

Login Hint

Hipstabank signalled Integral Curve to help initiate a login

Identifier First Login Flow

Integral Curve took the hint, only prompted for password

Account Record Stored

Hipstabank pushed an identifier and provider id into Account Chooser

AccountChooser Record Selected

Alice can click once to discover IDP, identify user, initiate SSO

^™

19 of 30

What you Saw in the Demo

Account Event Detect & Publish
Signal Generation
Downstream Security Decisions

Session invalidation
Token Revocation

^™

20 of 30

YOUR �APP

eric@gmail.com

Choose an account

Eric Sachs

eric@playthesachs.biz

Eric Sachs

esachs@google.com

Eric Sachs

eric@gmail.com

CANCEL

YOUR �APP

eric@gmail.com

Choose a method

CANCEL

Create a password

@

YOUR �APP

eric@gmail.com

Choose an account

Eric Sachs

esachs@google.com

Eric Sachs

eric@gmail.com

CANCEL

Thank you for �registering, Eric

Eric Sachs

eric@gmail.com

^™

We discussed users with an IDP, and users with a password.
But how about users who are not yet registered, especially on a consumer app?
In that case the app can show a UX like the second screen with buttons for popular identity providers, or the ability to use a password.
That enables the user to decide how they want their new account to be authenticated.
Google obviously hopes many apps, both consumer & SaaS, will offer a Google login option.
You may have heard of Google+ SignIn which is Google’s social login product. However we have always had the ability to just do basic login with a Google Account without any social features. Over the last few months we have cleaned up our developer documentation to make that more clear.
Let’s say the user clicks the blue Google signin button.
In that case, Google will show a list of the active Google accounts and get the user to give their consent by choosing one of them
That user experience with two account choosers is obviously a bit ugly. Fortunately OpenIDConnect makes it much simpler

If the IDP a user chooses on the 2nd screen supported OpenIDConnect, then the app can pass an “identifier hint” to the IDP with the email address it already has for the user. It can then indicate to the IDP that all it wants to know is whether that IDP thinks there is a valid session on that device for that email identifier
As an example, if Google were the IDP, we sould see 2 active sessions, and one would match the identifier hint, so we would immediately respond with a “yes” in the form of an IDToken
So that gets rid of 1 step in the flow, and avoids the double account chooser UX
The OIDC workgroup calls this the FastIdentifierVerification flow
However its possible in some cases to do even better then that...

21 of 30

YOUR �APP

eric@gmail.com

Choose an account

Eric Sachs

eric@playthesachs.biz

Eric Sachs

esachs@google.com

Eric Sachs

eric@gmail.com

CANCEL

Thank you for �registering, Eric

Eric Sachs

eric@gmail.com

Yep!

eric@

gmail.com?

Google

Fast IDV

^™

22 of 30

^™

23 of 30

^™

24 of 30

All you need to do is build this…

^™

25 of 30

Google Identity Toolkit

^™

So we are more and more aggressively promoting the idea of apps using a Login-as-a-Service offering
Google itself has such a Login-as-a-Service offering called Google Identity Toolkit
It supports pretty much every trick we just discussed, along with many other we did not have time to cover.
The one big piece missing is support for SmartLock, but we expect to add that in the next few months. Fortunately app developer’s generally don’t need to write new code when we add support for new features like SmartLock.
And that is the power of Login-as-a-Service offerings. App owners generally get the new features without having to make any changes.
We hope that OTHER Login-as-a-Service offerings will similarly add support for these numerous tricks in the future, especially as they get standardized

26 of 30

For your employees...

Pick an IDaaS provider from the many vendors in the market
Or combine them as Netflix did (Google Apps + Ping “Identity Bridge”)

^™

27 of 30

Search for “Google Internet Identity Research” to find these slides and others from Google

^™

28 of 30

NEW YORK

^™

29 of 30

SAN FRANCISCO

^™

30 of 30

LONDON

^™