Instead of maintaining your own authentication database, you might use one from a third-party. In this video, you’ll learn about federation, SAML, OpenID Connect, and OAuth.
Federation is a way that you could provide access to your network using credentials that someone uses for a completely different service. This can be done for users that are on your local network or you could use this for third party individuals such as partners or customers to be able to gain access to your server.
You probably seen the login screen like this before that isn’t asking you to login with some credentials that you’ve previously created on that site. It’s asking you to login with credentials you may already have at Twitter, Facebook, at LinkedIn or at other locations. This means that you can use authentication credentials that you already use and maintain without having to recreate additional login credentials for the site.
Of course, the site you’re visiting and these third party sites need to already have a relationship and a trust built between them. And there’s usually a number of configuration steps so that third parties can use these authentication methods for users to login to the local site.
There have been a number of different standards used through the years to allow someone to authenticate and authorize someone to access a third party set of resources. One of these standards is SAML. This is the Security Assertion Markup Language and it was designed to provide both authentication and authorization for users to access third party resources.
This one standard provides a great deal of functionality unless of course you’re a mobile app. SAML was never designed to be used for mobile applications where someone might be accessing a resource from multiple devices simultaneously. And for that reason you may see the use of SAML declining as the years go on.
The SAML process is relatively straightforward. Let’s say you’re here in a browser needing to access a third party site which we’ll call our resource server. But we want to authenticate to that resource server using credentials that exist on a completely different service. And that service provides a way to authorize those credentials through an authorization server.
So how do we get all three of these resources to talk to each other. Well, the first thing we’re going to do is try to access the application. So we’ll go to our browser and put in the website to gain access to that particular site. This site says that we have not previously authenticated. So it sends us back a sign an encrypted SAML request and says, for you to be able to login you need to send this request to the authorization server.
Will then communicate with the authorization server with our login credentials and will include this signed an encrypted SAML request. If our username and password is correct that authorization server will send us back a successful notification and will include a SAML token with that response. We can now present that same token to the original third party website. And now that site sees that we have a valid token it can allow us access to that service.
A more common way to provide authentication and authorization for our mobile devices and our browsers is to use some newer types of protocols. These newer standards consist of OpenID Connect and OAuth. OAuth is a framework that allows us to control what types of resources a third party application may be able to access. This framework was created by Google, Twitter, and a number of other companies. And it has very broad support in the industry.
Unlike SAML, which provided authentication and authorization, OAuth is usually used in conjunction with OpenID Connect. So OpenID Connect is providing all of the authentication functionality. And then OAuth is determining what types of data is accessible by that third party app once the authentication is complete.
This is a very popular framework and you’ll see it used on Google, Facebook, Twitter and many, many other sites. You’ve probably seen a message like this when you’ve wanted to have one particular application share data from a completely different site. This is an example of a site called Zapier that allows me to automate a number of backend processes. And I want Zapier to be able to modify information that’s in my Google Drive directory.
Well obviously Zapier is not Google and so there needs to be some type of authorization between the Zapier website and the Google website. So I’ve told Zapier that, I’d like to begin the process of allowing it to see, edit, create or delete files that are in my Google Drive. And then I can decide whether that particular application has access to my Google account. And how much access it happens to have.
This means that I can set up this trust between these two applications without having to hand over any of my login credentials for either of these sites. And at any time if I would like to remove this particular link between these sites I simply remove the key and it no longer has access to Google Drive.