Authentication and authorization

Providing authentication and authorization is de facto for web applications. We'll discuss authentication and authorization in this section. The new paradigm that has evolved over the past few years is OAuth. We'll learn and use OAuth 2.0 for implementation. OAuth is an open authorization mechanism, implemented in every major web application. Web applications can access each other's data by implementing the OAuth standard. It has become the most popular way to authenticate oneself for various web applications. Like on www.quora.com, you can register, and login using your Google or Twitter login IDs. It is also more user friendly, as client applications (for example, www.quora.com) don't need to store the user's passwords. The end user does not need to remember one more user ID and password.

OAuth 2.0 example usage

OAuth 2.0

The Internet Engineering Task Force (IETF) governs the standards and specifications of OAuth. OAuth 1.0a was the most recent version before OAuth 2.0 that was having a fix for session-fixation security flaw in the OAuth 1.0. OAuth 1.0 and 1.0a were very different from OAuth 2.0. OAuth 1.0 relies on security certificates and channel binding. OAuth 2.0 does not support security certification and channel binding. It works completely on Transport Security Layer (TSL). Therefore, OAuth 2.0 does not provide backward compatibility.

Usage of OAuth

• As discussed, it can be used for authentication. You might have seen it in various applications, displaying messages such as sign in using Facebook or sign in using Twitter.
• Applications can use it to read data from other applications, such as by integrating a Facebook widget into the application, or having a Twitter feed on your blog.
• Or, the opposite of the previous point can be true: you enable other applications to access the end user's data.

OAuth 2.0 specification – concise details

We'll try to discuss and understand the OAuth 2.0 specifications in a concise manner. Let's first see how signing in using Twitter works.

Please note that the process mentioned here was used at the time of writing. It may change in future. However, this process describes one of the OAuth 2.0 processes properly:

1. The user visits the Quora home page. It shows various login options. We'll explore the process of the Continue with Twitter link.
2. When the user clicks on the Continue with Twitter link, Quora opens a new window (in Chrome) that redirects the user to the www.twitter.com application. During this process few web applications redirect the user to the same opened tab/window.
3. In this new window/tab, the user signs in to www.twitter.com with their credentials.
4. If the user has not authorized the Quora application to use their data earlier, Twitter asks for the user's permission to authorize Quora to access the user's information. If the user has already authorized Quora, then this step is skipped.
5. After proper authentication, Twitter redirects the user to Quora's redirect URI with an authentication code.
6. Quora sends the client ID, client secret token, and authentication code (sent by Twitter in step 5) to Twitter when Quora redirect URI entered in the browser.
7. After validating these parameters, Twitter sends the access token to Quora.
8. The user is logged in to Quora on successful retrieval of the access token.
9. Quora may use this access token to retrieve user information from Quora.

You must be wondering how Twitter got Quora's redirect URI, client ID, and secret token. Quora works as a client application and Twitter as an authorization server. Quora, as a client, registered on Twitter by using Twitter's OAuth implementation to use resource owner (end user) information. Quora provides a redirect URI at the time of registration. Twitter provides the client ID and secret token to Quora. It works this way. In OAuth 2.0, user information is known as user resources. Twitter provides a resource server and an authorization server. We'll discuss more of these OAuth terms in the next sections.

OAuth 2.0 example process for signing in with Twitter

OAuth 2.0 roles

There are four roles defined in the OAuth 2.0 specifications:

• Resource owner
• Resource server
• Client
• Authorization server
  

  OAuth 2.0 roles

Resource owner

For the Quora sign in using Twitter example, the Twitter user was the resource owner. The resource owner is an entity that owns the protected resources (for example user handle, tweets and so on) that are to be shared. This entity can be an application or a person. We call this entity the resource owner because it can only grant access to its resources. Specification also defines, when resource owner is a person, it is referred to as an end user.

Resource server

The resource server hosts the protected resources. It should be capable of serving the access requests to these resources using access tokens. For the Quora sign in using Twitter example, Twitter is the resource server.

Client

For the Quora sign in using Twitter example, Quora is the client. The client is the application that makes access requests for protected resources to the resource server on behalf of the resource owner.

Authorization server

The authorization server provides different tokens to the client application, such as access tokens or refresh tokens, only after the resource owner authenticates themselves.

OAuth 2.0 does not provide any specifications for interactions between the resource server and the authorization server. Therefore, the authorization server and resource server can be on the same server, or can be on a separate one.

A single authorization server can also be used to issue access tokens for multiple resource servers.

OAuth 2.0 client registration

The client that communicates with the authorization server to obtain the access key for a resource should first be registered with the authorization server. The OAuth 2.0 specification does not specify the way a client registers with the authorization server. Registration does not require direct communication between the client and the authorization server. Registration can be done using self-issued or third-party-issued assertions. The authorization server obtains the required client properties using one of these assertions. Let's see what the client properties are:

• Client type (discussed in the next section).
• Client redirect URI, as we discussed in the Quora sign in using Twitter example. This is one of the endpoints used for OAuth 2.0. We will discuss other endpoints in the Endpoints section.
• Any other information required by the authorization server, for example client name, description, logo image, contact details, acceptance of legal terms and conditions, and so on.

Client types

There are two types of client described by the specification, based on their ability to maintain the confidentiality of client credentials: confidential and public. Client credentials are secret tokens issued by the authorization server to clients in order to communicate with them.

Confidential client type

This is a client application that keeps passwords and other credentials securely or maintains them confidentially. In the Quora sign in using Twitter example, the Quora app server is secure and has restricted access implementation. Therefore, it is of the confidential client type. Only the Quora app administrator has access to client credentials.

Public client type

These are client applications that do not keep passwords and other credentials securely or maintain them confidentially. Any native app on mobile or desktop, or an app that runs on browser, are perfect examples of the public client type, as these keep client credentials embedded inside them. Hackers can crack these apps and the client credentials can be revealed.

A client can be a distributed component-based application, for example, it could have both a web browser component and a server-side component. In this case, both components will have different client types and security contexts. Such a client should register each component as a separate client if the authorization server does not support such clients.

Based on the OAuth 2.0 client types, a client can have the following profiles:

• Web application
• User agent-based application
• Native application

Web application

The Quora web application used in the Quora sign in using Twitter example is a perfect example of an OAuth 2.0 web application client profile. Quora is a confidential client running on a web server. The resource owner (end user) accesses the Quora application (OAuth 2.0 client) on the browser (user agent) using a HTML user interface on his device (desktop/tablet/cell phone). The resource owner cannot access the client (Quora OAuth 2.0 client) credentials and access tokens, as these are stored on the web server. You can see this behavior in the diagram of the OAuth 2.0 sample flow. See steps 6 to 8 in the following figure:

OAuth 2.0 client web application profile

User agent-based application

User agent-based applications are of the public client type. Here, though, the application resides in the web server, but the resource owner downloads it on the user agent (for example, a web browser) and then executes the application. Here, the downloaded application that resides in the user agent on the resource owner's device communicates with the authorization server. The resource owner can access the client credentials and access tokens. A gaming application is a good example of such an application profile.

OAuth 2.0 client user agent application profile

Native application

Native applications are similar to user agent-based applications, except these are installed on the resource owner's device and execute natively, instead of being downloaded from the web server, and then executes inside the user agent. Many native clients (mobile apps) you download on your mobile are of the native application type. Here, the platform makes sure that other application on the device do not access the credentials and access tokens of other applications. In addition, native applications should not share client credentials and OAuth tokens with servers that communicate with native applications.

OAuth 2.0 client native application profile

Client identifier

It is the authorization server's responsibility to provide a unique identifier to the registered client. This client identifier is a string representation of the information provided by the registered client. The authorization server needs to make sure that this identifier is unique. The authorization server should not use it on its own for authentication.

The OAuth 2.0 specification does not specify the size of the client identifier. The authorization server can set the size, and it should document the size of the client identifier it issues.

Client authentication

The authorization server should authenticate the client based on their client type. The authorization server should determine the authentication method that suits and meets security requirements. It should only use one authentication method in each request.

Typically, the authorization server uses a set of client credentials, such as the client password and some key tokens, to authenticate confidential clients.

The authorization server may establish a client authentication method with public clients. However, it must not rely on this authentication method to identify the client, for security reasons.

A client possessing a client password can use basic HTTP authentication. OAuth 2.0 does not recommend sending client credentials in the request body. It recommends using TLS and brute force attack protection on endpoints required for authentication.

OAuth 2.0 protocol endpoints

An endpoint is nothing but a URI we use for REST or web components such as Servlet or JSP. OAuth 2.0 defines three types of endpoint. Two are authorization server endpoints and one is a client endpoint:

• Authorization endpoint (authorization server endpoint)
• Token endpoint (authorization server endpoint)
• Redirection endpoint (client endpoint)

Authorization endpoint

This endpoint is responsible for verifying the identity of the resource owner and, once verified, obtaining the authorization grant. We'll discuss the authorization grant in the next section.

The authorization server require TLS for the authorization endpoint. The endpoint URI must not include the fragment component. The authorization endpoint must support the HTTP GET method.

The specification does not specify the following:

• The way the authorization server authenticates the client.
• How the client will receive the authorization endpoint URI. Normally, documentation contains the authorization endpoint URI, or the client obtains it at the time of registration.

Token endpoint

The client calls the token endpoint to receive the access token by sending the authorization grant or refresh token. The token endpoint is used by all authorization grants except an implicit grant.

Like the authorization endpoint, the token endpoint also requires TLS. The client must use the HTTP POST method to make the request to the token endpoint.

Like the authorization endpoint, the specification does not specify how the client will receive the token endpoint URI.

Redirection endpoint

The authorization server redirects the resource owner's user agent (for example, a web browser) back to the client using the redirection endpoint, once the authorization endpoint's interactions are completed between the resource owner and the authorization server. The client provides the redirection endpoint at the time of registration. The redirection endpoint must be an absolute URI and not contain a fragment component.

OAuth 2.0 endpoints

OAuth 2.0 grant types

The client requests an access token from the authorization server, based on the obtained authorization from the resource owner. The resource owner gives authorization in the form of an authorization grant. OAuth 2.0 defines four types of authorization grant:

• Authorization code grant
• Implicit grant
• Resource owner password credentials grant
• Client credentials grant

OAuth 2.0 also provides an extension mechanism to define additional grant types. You can explore this in the official OAuth 2.0 specifications.

Authorization code grant

The first sample flow that we discussed in the OAuth 2.0 example flow for signing in with Twitter depicts an authorization code grant. We'll add a few more steps for the complete flow. As you know, after the eighth step, the end user logs in to the Quora application. Let's assume the user is logging in to Quora for the first time and requests their Quora profile page:

1. After logging in, the Quora user clicks on their Quora profile page.
2. The OAuth client Quora requests the Quora user's (resource owner) resources (for example, Twitter profile photo and so on) from the Twitter resource server and sends the access token received in the previous step.
3. The Twitter resource server verifies the access token using the Twitter authorization server.
4. After successful validation of the access token, the Twitter resource server provides the requested resources to Quora (OAuth client).
5. Quora uses these resources and displays the Quora profile page of the end user.

Authorization code requests and responses

If you looked at all the steps (a total of 13) of the authorization code flow, you can see that there are a total of two requests made by the client to the authorization server, and the authorization server in reply provides two responses: one request-response for the authentication token and one request-response for the access token.

Let's discuss the parameters used for each of these requests and responses.

OAuth 2.0 authorization code grant flow

The authorization request (step 4) to the authorization endpoint URI:

Parameter	Required / Optional	Description
response_type	Required	code (this value must be used).
client_id	Required	It represents the ID issued by the authorization server to the client at the time of registration.
redirect_uri	Optional	It represents the redirect URI given by the client at the time of registration.
scope	Optional	The scope of the request. If not provided, then the authorization server provides the scope based on the defined policy.
state	Recommended	The client uses this parameter to maintain the client state between the requests and callback (from the authorization server). The specification recommends it to protect against cross site request forgery attacks.

Authorization response (step 5):

Parameter	Required / Optional	Description
code	Required	Code (authorization code) generated by the authorization server. Code should be expired after it is generated; the maximum recommended lifetime is 10 minutes. The client must not use the code more than once. If the client uses it more than once, then the request must be denied and all previous tokens issued based on the code should be revoked. Code is bound to the client ID and redirect URI.
state	Required	It represents the ID issued by the authorization server to the client at the time of registration.

Token request (step 7) to token endpoint URI:

Parameter	Required / Optional	Description
grant_type	Required	authorization_code (this value must be used).
code	Required	Code (authorization code) received from the authorization server.
redirect_uri	Required	Required if it was included in the authorization code request and the values should match.
client_id	Required	It represents the ID issued by the authorization server to the client at the time of registration.

Token response (step 8):

Parameter	Required / Optional	Description
access_token	Required	The access token issued by the authorization server.
token_type	Required	The token type defined by the authorization server. Based on this, the client can utilize the access token. For example, bearer or mac.
refresh_token	Optional	This token can be used by the client to get a new access token using the same authorization grant.
expires_in	Recommended	Denotes the lifetime of the access token in seconds. A value of 600 denotes 10 minutes of lifetime for the access token. If this parameter is not provided in the response, then the document should highlight the lifetime of the access token.
scope	Optional/Required	Optional if identical to the scope requested by the client. Required if the access token scope is different from the one the client provided in their request to inform the client about the actual scope of the access token granted. If the client does not provide the scope while requesting the access token, then the authorization server should provide the default scope, or deny the request, indicating the invalid scope.

Error response:

Parameter	Required / Optional	Description
error	Required	One of the error codes defined in the specification, for example, unauthorized_client, invalid_scope.
error_description	Optional	Short description of the error.
error_uri	Optional	The URI of the error page describing the error.

An additional error parameter state is also sent in the error response if the state was passed in the client authorization request.

Implicit grant

The first sample flow that we discussed in the OAuth 2.0 example flow for signing in with Twitter depicts the authorization code grant. We'll add a few more steps for its complete flow. As you know after eighth steps, end user logs in to the Quora application. Let's assume user is logging in first time on Quora and requests for its Quora profile page:

1. Step 9: After login, the Quora user clicks on their Quora profile page.
2. Step 10: The OAuth client Quora requests the Quora user's (resource owner) resources (for example, Twitter profile photo and so on) from the Twitter resource server and sends the access token received in the previous step.
3. Step 11: The Twitter resource server verifies the access token using the Twitter authorization server.
4. Step 12: After successful validation of the access token, the Twitter resource server provides the requested resources to Quora (OAuth client).
5. Step 13: Quora uses these resources and displays the Quora profile page of the end user.

Implicit grant requests and responses

If you looked at all the steps (a total of 13) of the authorization code flow, you can see that there are total of two request made by the client to the authorization server, and the authorization server in reply provides two responses: one request-response for the authentication token and one request-response for the access token.

Let's discuss the parameters used for each of these requests and responses.

Authorization request to the authorization endpoint URI:

Parameter	Required / Optional	Description
response_type	Required	Token (this value must be used).
client_id	Required	It represents the ID issued by the authorization server to the client at the time of registration.
redirect_uri	Optional	It represents the redirect URI given by the client at the time of registration.
scope	Optional	The scope of the request. If not provided, then the authorization server provides the scope based on the defined policy.
state	Recommended	The client uses this parameter to maintain the client state between the requests and the callback (from the authorization server). The specification recommends it to protect against cross site request forgery attacks.

Access token response:

Parameter	Required / Optional	Description
access_token	Required	The access token issued by the authorization server.
token_type	Required	The token type defined by the authorization server. Based on this, the client can utilize the access token. For example, bearer or mac.
refresh_token	Optional	This token can be used by the client to get a new access token using the same authorization grant.
expires_in	Recommended	Denotes the lifetime of the access token in seconds. A value of 600 denotes 10 minutes of lifetime for the access token. If this parameter is not provided in the response, then the document should highlight the lifetime of the access token.
scope	Optional/Required	Optional if identical to the scope requested by the client. Required if the access token scope is different from the one the client provided in the request to inform the client about the actual scope of the access token granted. If the client does not provide the scope while requesting the access token, then the authorization server should provide the default scope, or deny the request, indicating the invalid scope.
State	Optional/Requried	Required if the state was passed in the client authorization request.

Error response:

Parameter	Required / Optional	Description
error	Required	One of the error codes defined in the specification, for example, unauthorized_client, invalid_scope.
error_description	Optional	Short description of the error.
error_uri	Optional	The URI of the error page describing the error.

An additional error parameter state is also sent in the error response if the state was passed in the client authorization request.

Resource owner password credentials grant

The first sample flow that we discussed in the OAuth 2.0 example flow for signing in with Twitter depicts the authorization code grant. We'll add a few more steps for its complete flow. As you know, after the eighth step, the end user logs in to the Quora application. Let's assume the user is logging in to Quora for the first time and requests their Quora profile page:

1. Step 9: After login, the Quora user clicks on their Quora profile page.
2. Step 10: The OAuth client Quora requests the Quora user's (resource owner) resources (for example, Twitter profile photo and so on) from the Twitter resource server and sends the access token received in the previous step.
3. Step 11: The Twitter resource server verifies the access token using the Twitter authorization server.
4. Step 12: After successful validation of the access token, the Twitter resource server provides the requested resources to Quora (OAuth client).
5. Step 13: Quora uses these resources and displays the Quora profile page of the end user.

Resource owner password credentials grant requests and responses.

As seen in the previous section, in all the steps (a total of 13) of the authorization code flow, you can see that there are total of two requests made by the client to the authorization server, and the authorization server in reply provides two responses: one request-response for the authentication token and one request-response for the access token.

Let's discuss the parameters used for each of these requests and responses.

Access token request to the token endpoint URI:

Parameter	Required / Optional	Description
grant_type	Required	Password (this value must be used).
username	Required	Username of the resource owner.
password	Required	Password of the resource owner.
scope	Optional	The scope of the request. If not provided, then the authorization server provides the scope based on the defined policy.

Access token response (step 8):

Parameter	Required / Optional	Description
access_token	Required	The access token issued by the authorization server.
token_type	Required	The token type defined by the authorization server. Based on this, the client can utilize the access token. For example, bearer or mac.
refresh_token	Optional	This token can be used by the client to get a new access token using the same authorization grant.
expires_in	Recommended	Denotes the lifetime of the access token in seconds. A value of 600 denotes 10 minutes of lifetime for the access token. If this parameter is not provided in the response, then the document should highlight the lifetime of the access token.
Optional parameter	Optional	Additional parameter.

Client credentials grant

The first sample flow that we discussed in the OAuth 2.0 example flow for signing in with Twitter depicts the authorization code grant. We'll add a few more steps for its complete flow. As you know, after the eighth step, the end user logs in to the Quora application. Let's assume the user is logging in to Quora for the first time and requests their Quora profile page:

1. Step 9: After login, the Quora user clicks on their Quora profile page.
2. Step 10: The OAuth client Quora requests the Quora user's (resource owner) resources (for example, Twitter profile photo and so on) from the Twitter resource server and sends the access token received in the previous step.
3. Step 11: The Twitter resource server verifies the access token using the Twitter authorization server.
4. Step 12: After successful validation of the access token, the Twitter resource server provides the requested resources to Quora (OAuth client).
5. Step 13: Quora uses these resources and displays the Quora profile page of the end user.

Client credentials grant requests and responses.

If you looked at all the steps (a total of 13) of the authorization code flow, you can see that there are total of two requests made by the client to the authorization server, and the authorization server in reply provides two responses: one request-response for the authentication token and one request-response for the access token.

Let's discuss the parameters used for each of these requests and responses.

Access token request to the token endpoint URI:

Parameter	Required / Optional	Description
grant_type	Required	client_credentials (this value must be used).
scope	Optional	The scope of the request. If not provided, then the authorization server provides the scope based on the defined policy.

Access token response:

Parameter	Required / Optional	Description
access_token	Required	The access token issued by the authorization server.
token_type	Required	The token type defined by the authorization server. Based on this, the client can utilize the access token. For example, bearer or mac.
expires_in	Recommended	Denotes the lifetime of the access token in seconds. A value of 600 denotes 10 minutes of lifetime for the access token. If this parameter is not provided in the response, then the document should highlight the lifetime of the access token.