Agile Authentication in Modern Applications—With OAuth 2.0

For some websites, when logging in–whether to receive a service or make a purchase–you may have noticed a new type of login that prompts the user with options to login with Google and other third-party social identity provider services. An example of such a login is the Coursera.org login shown in Figure 1.

Figure 1. Login with third-party service providers

Firstly, why is the user being prompted to Continue with the login using social identity providers? Simply, to avoid having a user create an account, or register with the Coursera.org website with Sign up, which is still an option. Modern applications make use of the smooth login authentication using social identity providers.

Secondly, how is a third-party social identity provider based login set-up? Third-party login is an authentication layer on top of an authorization layer. The identity authentication is performed by an authorization server on the chosen social identity provider using OAuth 2.0 protocol. OAuth 2.0 is designed for use with HTTP only.

What Is OAuth 2.0?

The OAuth 2.0 is an authorization framework that enables a third-party application to obtain a limited access to an HTTP service. OAuth 2.0 defines some terms, and roles that are used.

A protected resource is a resource such as user information.

A resource server is the server on which a protected resource is stored.

A resource owner is the one who owns a protected resource and is able to grant access to it.

A client is one who wants to access a protected resource.

An authorization server is a server that obtains authorization on behalf of the client. It returns access tokens to the client with which a client may access a protected resource. The access tokens are limited in scope such as they may be valid for a limited time and for a limited subset of resources. The authorization server could be the same as the authentication server.

Login Authentication Example 

For a login, a client website, using Coursera.org as an example, is interested in authenticating a user using one of the user’s social identity provider accounts, (if the user has one) and obtaining user information such as name and email from the social identity provider account. For Coursera to be able to authenticate its users using a Google, or another identity provider account, it must have registered as a client with the identity providers.

In the example login illustrated in Figure 1, if the user selects Continue with Google, the request is sent to Coursera’s backend server, and the server sends a redirect URL directed at Google’s authorization server to the user’s browser, which acts as a user agent. The redirect URL includes oauth2/v2/auth, which implies that OAuth 2.0 is used for authentication. The URL also includes as request parameters the Coursera’s client id registered with Google, and a URL directed at Coursera’s backend server that the Google’s authorization server can use to construct a redirect URL to send back to the user’s browser. The user is prompted to provide a Google account email as shown in Figure 2. The user then provides an account email and clicks on Next.

Figure 2. Sign in to Google to continue to Coursera

Continuing with the example login, the user provides the password for its Google account and clicks on Next as shown in Figure 3.

Figure 3. User provides password to authenticate with Google

The authentication request is sent to Google’s authorization server. The server authenticates the user, and if the email & password are valid, the server constructs a redirect URL directed at Coursera’s backend server and includes as a request parameter an authorization code that Coursera can use to access Google’s authorization server. The redirect URL is sent to the user’s browser. A message at the bottom of the redirect URL window indicates that Google will share the name, email, and language preference with Coursera.org as shown in Figure 4.

Figure 4. Sign in message

The authorization code exchange happens transparently to the user using the redirect URL. Once the authorization code has been sent to Coursera, the user’s input is not needed any more. When Google, or another social identity provider is used for proxying a login, the user’s credentials registered with the social identity providers such as Google account password are not shared with, or made available to, the client website; Coursera.org in the example.

Coursera, as Google’s client, sends a request to Google’s authorization server and includes the authorization code in the request. Google’s authorization server authorizes Coursera, its client, and returns an access token to Coursera; an access token that Coursera can use to access user’s information, the protected resource in the example. Coursera uses the access token to connect with the resource server and access the user’s information. The exchanges between Coursera’s server and Google’s servers happen transparently to the user. If all authorizations get validated, the user gets logged in to Coursera’s website as shown in Figure 5.

Figure 5. User logged in to Coursera

Authentication Sequence

Using the Cousera.org login as an example, the sequence used by authentication is as follows:

1. The user clicks on the Log in link on Coursera.org website.
2. The user is directed to a Login page or window.
3. The user chooses a social identity provider, as an example Google. The user clicks on Continue with Google, which is shown in Figure 1.
4. The user is directed to the Sign in window shown in Figure 2.
5. The user provides a Google account email and clicks on Next.
6. The user is prompted to provide the Google account password, which the user does and clicks on Next as shown in Figure 3. If the user is already logged in to the Google account that is to be used for authenticating the user, the account email is displayed to the user, and the user only needs to select the account.
7. If the user authenticates with Google’s authorization server, the server returns a redirect URL to the user’s browser directed at Coursera’s server. The redirect URL includes an authorization code. User has no more role to play in the authentication process.
8. The client (Coursera.org) makes an authorization request to Google’s authorization server and includes the authorization code in the request.
9. Google’s authorization server authenticates the authorization code and returns an access token to Coursera.
10. Coursera connects with Google’s resource server using the access token to get user’s information.
11. The resource server validates the access token, and returns the user information to the client, Coursera.
12. The user gets logged in to Coursera.

In this article, we discussed using the OAuth 2.0 authorization framework for authenticating a user on a third-party HTTP website. Such a social identity provider based authentication makes use of what is called authorization code grant flow.