Authentication and authorization: The key to single sign-on (SSO) workflow

Single sign-on (SS0) technology at the enterprise level has been around for a while. Requiring employees to maintain special login credentials for each of the many applications used in their day-to-day work was not only annoying, it was also inefficient.

Fortunately, technologies such as LDAP and Active Directory made it so that users could maintain one set of login credentials to implement a single sign-on experience. These worked well as long as all the applications lived within the private boundaries of the enterprise. As external applications such as Salesforce and WebEx became commonplace in the enterprise, a new way of allowing access to applications was needed. The solution was to use new sign-on protocols that permitted communication between third-party identity providers.

Security Assertion Markup Language (SAML) was one of the first of the new protocols. OAuth soon followed, as did OpenID. In addition to providing a new way to allow users access to external applications, these protocols also created a novel technique by which access to user information was authorized.

[ Learn about the Zero-Trust approach to designing security architectures. ]

In the past, all access was granted according to direct authentication. A user entered a username/password pair directly into an application's form to get access. Today, under SAML, OAuth, and OpenID, access to an application is done using a third-party authentication mechanism known as an identity provider (IdP). An identity provider can also authorize requesting parties access to a particular user's information on behalf of the user.

In this article, we're going to examine the difference between direct authentication and third-party authentication. We'll also discuss how to use third-party authorization to grant an external website access to user information stored with the identity provider.

Understanding direct authentication

Direct authentication is the process by which a user or service logs into a network or domain using either a username/password pair or special access token. Direct authentication has been around for as long as there have been multi-user systems.

In a direct authentication scenario, user access credentials are stored in a secure location, usually a database within the application requiring credentialed access. Typically the credentials, either username and password or token, are stored in an encrypted format, thus preventing malicious actors from using secure data for nefarious purposes in the event of a breach.

Figure 1 shows an example of a conceptual implementation of direct authentication to a fictitious website, Big Social Network.

Figure 1: Under direct authentication, users login directly to a website according to a security-sensitive username and password

In addition to being a social network, Big Social Network is also its own authentication provider. Hence, all username and password management for Big Social Network is done through Big Social Network's own identity management capabilities. In other words, Big Social Network is its own identity provider.

This idea of an identity provider (IdP) is an important concept when considering third-party authentication of which, SAML, OAuth, and OpenID are examples. Identity providers enable third-party authentication and thus make it so that any application or service on the internet can leverage an identity provider's authentication capabilities to its own benefit.

Understanding third-party authentication

As mentioned above, third-party authentication allows any application or service on the internet to use the authentication services of another website to its own benefit. Operationally this means that a website, for example, the fictitious site Bob's Books, can delegate access to another website that supports identity management.

To put it another way, instead of asking users to register a username and password and then manage everything that goes along with that registration, Bob's Books can just rely upon Big Social Network's authentication capabilities to do the work. Figure 2 illustrates the workflow. The details follow.

Figure 2: Users submit a username and password to a known third-party for authentication

Figure 2 above illustrates how Bob's Books uses Big Social Network's identity provider capability to support secure login to its own site. Before we discuss the details of the process, it's important to understand that for Bob's Books to use Big Social Network, both entities need to know about each other.

When Bob's Books decided that it wanted to use Big Social Network to authenticate users, it sent a formal request to Big Social Network asking permission to leverage the social media site's login capabilities. (At the operational level, Bob's Books decided to use OAuth2 as the way to support login with Big Social Network. You can read the details of OAuth2 here.)

Upon receiving the request from Bob's Books, Big Social Network did the work of ensuring that Bob's Books was genuine. Once verified, Big Social Network gave Bob's Books a process by which to access the Big Social Network login page in a way that is specific to Bob's Books. And, Bob's Books provided Big Social Network with a way to respond back to it once the Big Social Network login was successful. In other words, even before third-party authentication could take place, both Bob's Books and Big Social Network needed to be well aware of each other.

The actual mechanics of third-party authentication shown above in Figure 2 are as follows. Mary goes to bobsbooks.com. Because she is unknown to Bob's Books, she's presented with a web page that informs her that she can sign in to the site using Big Social Network. (Figure 2, callout 1) Mary clicks the "Sign in" button and is redirected to a URL represented by Big Social Network. Appended to the Big Social Network URL is a token identifying Bob's Books. Big Social Network parses out the URL, determines that the request is made on behalf of Bob's Books, and then presents a webpage allowing Mary to login to the Big Social Network under the aegis of Bob's Books. Mary enters her username and password.

Mary has authenticated to Bob's Books by way of Big Social Network. The next step will be to allow Big Social Network to share information about Mary with Bob's Books. This is where authorization comes into play.

Understanding third-party authorization

Authorization is the process by which a third party is granted permission to access information or perform an action associated with another entity. An example of third-party authorization is Mary permitting Big Social Network to allow Bob's Books to have access to her Big Social Network friends' email addresses.

In this example, the authorization is confined to viewing a particular piece of information. However, there are cases in which other actions can be authorized. For example, Mary permits Big Social Network to allow Bob's Books to post to her Big Social Network wall.

Figure 3 below illustrates the authentication process described above in Figure 2 to include authorization. Callout 1 in Figure 3 below picks up where Callout 2 in Figure 2 above left off. However, before moving on in the authorization process, we need to add an important piece of information we neglected to share earlier.

When Bob's Books decided to use Big Social Network to authenticate users, it also agreed that as part of the login process, it wanted to ask Mary for permission to access all the email addresses of her friends. Providing access to her friends' email addresses is not mandatory for authentication. It's an arbitrary request that Mary can decline, but it is still part of the sign-in process.

Let's take a look at the details.

Figure 3: A user can authorize a third party such as the fictitious site, Big Social Network, to share some or all of their personal data

In Figure 3 above, callout 1, Mary is redirected from Bob's Books over to Big Social Network, where she enters her username and password. Big Social Network takes Mary's credentials and compares them to the username and password it has stored in its identity database. The credentials match up. Since Big Social Network knows Mary and it knows that Bob's Books want to gain access to the email addresses of Mary's friends, Mary is presented with Big Social Network's web page asking if Mary does indeed want to share the email addresses with Bob's Books. (Figure 3, callout 2). Mary gives Big Social Network permission to share the email addresses. Then, Big Social Network redirects Mary back to Bob's Books. As part of the redirection, Big Social Network inserts a token in the URL to Bob's Books that indicates that Mary is indeed known to Big Social Network. Bob's Books allows Mary access to the website. (Figure 3, callout 3.)

It should be noted here that the way the information confirming Mary's authentication is passed back to Bob's Books is specific to the sign-on technique used. SAML does it one way, OAuth2 does it another way, and OpenId does it a third way. Regardless of which method is used, the important thing to know is that Bob's Books does not know Mary's username and password. That security-sensitive information is confined to the identity provider, in this case, Big Social Network.

There is one more task to perform once Bob's Books gives Mary access to its domain. Bob's Books needs to get the email addresses of Mary's friends. This is done behind the scenes between Bob's Books and Big Social Network.

Big Social Network knows that Mary has granted Bob's Books access to the email addresses of her friends. Also, part of the data exchanged during the authorization process is information that Bob's Books can use to get the email addresses of Mary's friends from Big Social Network. Thus, intelligence in the backend servers of Bob's Books contacts Big Social Network's backend servers requesting Mary's friends' email addresses. (Figure 3, callout 4). Big Social Network receives the request, internally confirms that Bob's Books can have the email addresses, and sends them. (Figure 3, callout 5.)

The sign-on and authorization process is complete.

Putting it all together

Using a third party to authenticate a user and then facilitate authorization to access that user's personal data is a powerful architectural technique that has fueled the growth of e-commerce on the internet. (See Figure 4, below)

Figure 4: Single sign-on and third-party authorization is a common feature of enterprise-level e-commerce

Single sign-on across domains reduces the labor of user credential management significantly, thus allowing websites and service providers to focus on their core business capabilities and leave the mundane yet critical tasks of security management to identity providers that are better suited to handle such work.

In this article, we covered the basic concepts that are necessary to implement single sign-on using third-party authentication. We also covered how to extend single sign-on to implement authorization on behalf of a user. Of course, the devil is always in the details. Single sign-on protocols such as SAML, OAuth, and OpenID each have particular ways of working. Hopefully, the concepts introduced in the article will provide a solid foundation that will reduce the time required to master particulars of the single sign-on technology of your choosing.