Implementing OAuth 2 in PWAs – Progressive Web App Training


SARAH CLARK: What
would it be like if you never needed
to maintain usernames or passwords on your own site? I’m Sarah Clark, and this is
your introduction to identity federation using OAuth 2. [MUSIC PLAYING] Imagine you have a service
where users need to sign in. How can you make this
as painless as possible? What if they’re already signed
in with someone you trust? Could you ask that other
service to authenticate them? You can do this using
identity federation. This is a way for users
to sign up or sign in using an account hosted on
a third party website called the identity provider. In technical terms, it lets you
replace identity verification on multiple services with
a single federated service. Web developers can choose
between multiple standards, including OpenID
Connect and OAuth. Both of these have the
exact same benefits. Users won’t need a new password,
and the identity provider handles any security challenges. When you use one
of those services, you can also receive profile
information from the provider. There are at least 40
identity providers worldwide. You’re probably
familiar with several of these OAuth providers. Of course, Google is
an identity provider. And in this session,
I’ll show you how to add the Google
Sign-In button to your site. Before we dive into the
code, let me show you how identity federation works. First, your user asks to sign
in to your application using a third party. Your app pops up or redirects
to the third party’s login page. At the same time, your
app identifies itself to the third party service. This is important. There needs to be a
trust relationship between the third
party and your app, just as there is between the
user and the third party. That chain of trust protects
you, the third party, and the user. Your app then waits
for confirmation that your user is logging in. The third party service
requests the user’s permission to share profile information. Once that’s approved,
your application can get the information
and the user is logged in. Now that you know
what the service does, let’s see how to implement it. First, you’ll need to get
an application identifier from Google. This begins the
trust relationship between Google and your site. Then you can add some meta
tags to your sign-in page that includes that identifier
and some sign-in options. You’ll also load the Sign
In With Google library. One line of HTML is all
you need to add the button, and a few lines of JavaScript
will retrieve the user data. I’ve already
registered a demo app. The first meta tag
sets some options, and the second has
my app identifier. Then I load the library using
async and defer for a fast time to render. One line of HTML
adds the button. Google’s library looks
for a specific CSS class and injects the button. Notice the attributes
with the data prefix. These let you attach
arbitrary data to a DOM node. In this case, we’re
adding the name of the success callback
and the color theme to use for the button. We’re calling our post
sign-in function onSignIn. Our sign-in function gets a
Google user data structure. We can ask for the basic
profile information and log it to the console. Notice that this profile
includes a user ID. For security reasons, you should
never send this copy of the ID back to your back end
for identifying the user. This is a plain string and a
man-in-the-middle attack could tamper with it. Instead, get an ID token
is shown below the comment. ID tokens are
cryptographically secure and can be verified
by your server. And there we have it, a
federated login using Google. You can use any
identity federation service that makes sense. This provides low
sign-in friction for users and easy APIs. If you want to try
this out for yourself, the OAuth code lab has a demo
app called the Ducky Debugger. You can add Google
Sign-In to this app. That’s it for
identity federation. It’s straightforward, and
well understood by users. But what if you wanted an
even easier way to login, such as with a fingerprint? See the Google I/O 2018
sessions for presentations on the Web Authentication API. Until then, thanks for
watching and I’ll see you soon. [MUSIC PLAYING]

1 Comment

  1. Yeah, but from what I can tell, you can't actually use the fingerprint sign in talked about in the I/O 2018 session. https://developers.google.com/identity/one-tap/web/ Did I look things up wrong?

Leave a Reply

Your email address will not be published. Required fields are marked *