Web applications (Resource Server) validate an access token before allowing a client application to access resources

Identity Server (authorization server) issues an access token and web applications (hosted on the resource server) validate the token before granting a client application to access resources. This configuration is applicable in the following scenarios:

Web server authentication

In a typical web authentication model, a client application uses a resource owner’s credentials to access the resource owner’s information hosted on a server.

A resource owner allows a printing service (client application) to access personal photos stored at a photo sharing service (server), without sharing credentials with the printing service. The user authenticates directly with the photo sharing service that issues the printing service delegation-specific credentials.

For example, Alice accesses an application running on a web server at www.printphotos.example. She instructs it to print her photographs stored on a server at www.storephotos.example. The application at www.printphotos.example receives Alice's authorization consent for accessing her photographs without learning her authentication credentials of www.storephotos.example. This example is derived from OAuth RFC.

The following diagram illustrates the workflow of the web server authentication:

Accessing resources without using owner’s credentials:

OAuth allows a client application to access resources controlled by the resource owner and provides a method to obtain permission from resource owners to access their resources. Resource owners provide this permission in the form of a token and a matching shared-secret. The resource owner does not need to share credentials with the client application. Tokens are issued with a restricted scope and limited life.

For example, a user Alice has installed a gaming application that runs in her browser. She uses OAuth for accessing a social site at www.example.com. The gaming application updates scores in a database at www.example.com. The gaming application is registered with the social site and has an identifier. She has registered with the social site for identification and authentication. To upload Alice's scores, the gaming application accesses the score database when she authorizes it. When she accesses the page from the redirect URI in the game application, the authorization server sends the client ID, password, and authentication code received in the redirect request parameters to www.example.com, which in turn returns an access token to the game application. The gaming application sends the token to www.example.com to access Alice’s resources. www.example verifies the token and grants the gaming application access to Alice’s account for updating the scores.

This example is derived from OAuth RFC.

RESTful applications security

OAuth provides a way to secure REST APIs. For example, an enterprise acme.com exposes REST APIs. Using OAuth, acme.com can ensure that the right people have access to these APIs. In addition, it can enable applications to call APIs on behalf of a user. It can also revoke access to an API even if an application uses it.

Figure 5-20 OAuth Flow

The following is the workflow:

  1. The client application requests authorization from a user (resource owner). Client applications can make the authorization request directly to the resource owner or through the authorization server (Identity Server) as an intermediary.

  2. The client application receives an authorization grant from the authorization server. An authorization grant represents the resource owner's authorization. The user communicates the authorization by using one of four grants types (see OAuth Authorization Grant) or by using an extension grant.

  3. The client application authenticates itself at the authorization server, sends the authorization grant, and requests an access token.

  4. The authorization server authenticates the client application and validates the authorization grant. The authorization server issues an access token for a valid grant.

  5. The client application requests the resource server to provide access to the protected resource and authenticates this by presenting the access token.

  6. The resource server accepts the request for a valid token.