Federated Login Providers

[00:00:00]
>> So before talking about WebAuthn, that's the most important API that we will cover today, let's talk a little bit and test federated login, at least once, what is that? That using OAuth you can use many providers, that is, login with GitHub, login with LinkedIn, okay? But yeah, that's kind of I mean, if you're using OAuth 2.0 with single pages applications, it's a little tricky, okay?

[00:00:33]
Because you need to open a URL that is not under your page, so it can be a pop up or you need to get out of your single page application, then go back. But fortunately, there are a couple of providers, actually two, Google and Apple, that they're providing already a very simplified version of that, where you actually don't need to implement OAuth yourself.

[00:00:58]
One is sign in with Google. In this case, okay, it's a whole system mechanisms just signing your website with different techniques with Google. It depends on the browser that the user is using and the platform if it's Android or if it Googly, it's a Google based platform, note, the experience that you will get with sign in with Google will be different.

[00:01:22]
Okay, sign in with Apple is also interesting, but we're not going to work with sign in with Apple today for two reasons. The first one, is that it doesn't work on local host. So testing it needs a server, a real domain. So, a step that we are not taking today.

[00:01:46]
And the second one, is that you need an Apple developer account. That means you need to pay $99 per year. So, as the website owner, okay, not as a user, as a website owner, you need to get some keys, to have security things, that you need to get the same account as when you are publishing apps to the App Store.

[00:02:10]
Even if you are not publishing any app to the App Store, okay, you need that account. I am not going to force you into paying that account today. So that's why also there are not so many websites out there with sign in with Apple. So when you compare how many websites are using sign in with Apple, you will see that if you have the largest one probably yes, but if you have a small website, yeah, you don't do that.

[00:02:36]
So, when you have sign in with Google you see something like this, probably you have seen these kind of pop ups and we're going to see those in our brochure in a minute and sign in with Apple has an interesting idea. Implement that also, that's why you also need to have an account with them.

[00:02:57]
So it's a more complex process internally, because when you apply sign in with Apple, you're also applying for this hide my email thing available in iOS and Safari on the Mac. The idea is that when you're implementing sign in with email, Safari will show you a native dialog to the user, saying hey, do you wanna sign in with your Apple account, your current account.

[00:03:28]
And I will share your email with this guy, with this provider, with this website or if you want, I can create a fake ID for you for this website and it creates a fake email, it hides my email. So it will give us as a website an email that works, but that email goes through Apple.

[00:03:55]
So it's an anonymous email. That then will be forwarded to the user and the user at any time can say you know what, I wanna delete that fake email, I don't wanna receive more email from these website. So then as a user you delete that and of course the website we'll never know who you was.

[00:04:17]
Okay, so that's hides my email and it's available only if you implement sign in with Apple. Okay, make sense? Yeah.
>> Is OAuth also an identity provider like OpenID or SAML?
>> No, OAuth is some kind of a slow protocol, okay? So the idea of OAuth version 2, that's the one that everyone is using right now, it's not actually a way to identify or authenticate users.

[00:04:46]
It's more a way to move identity information between different providers, okay? And it's one protocol available. So the quick idea, it has to do more with authorization than with authentication, but the whole idea is that I'm in my website, let's say coffeemaster.com. And I wanna open a login form but in google.com, so I don't manage google.com, I only manage coffeemasters.com.

[00:05:19]
So how can we do that? How can we handshake, how can I coffeemaster.com can have an agreement with google.com? So they will login you and they will pass credentials to me, but that flow of data is of 2.0, okay, so here's how you do that. It's one spec, actually the one that is being used a lot these days.

[00:05:45]
In fact lemme tell you something, 10 years ago, it was pretty common, you were actually logging in with Twitter, with Google. In other websites and other apps and you were actually typing your Google password, your Twitter password on other apps and they were storing in their servers your Twitter password or your Google password.

[00:06:11]
Of course that was a security issue, okay? Because when they have a data breach, now they don't have only access to your Twitter account or to your account on that website, but also Twitter or Google and your passwords were actually everywhere. Then the different providers invented this idea of app passwords.

[00:06:33]
I think that Google still has that somewhere it's still hidden, with app passwords you can create a password just from one app. So they can get into your account, but it's a password just for that app and you can even narrow permissions if someone is using that password.

[00:06:53]
But anyway, to avoid that problem, we came up with the solution of OAuth. We are not going to use OAuth, but we are going to use sign in with Google right now, that will give us a simple way to do that, so we can understand how that works.

[00:07:10]
And how can we adjust our web services and our database to work with federated logins. Okay then you can add on top of that OAuth or sign in with Apple or any other provider.