WAS v8.5 > Secure applications > Authorizing access to resources

OAuth

OAuth is an open standard for delegated authorization. The OAuth authorization framework allows a user to grant a third-party application access to their information stored with another HTTP service without sharing their access permissions or the full extent of their data.

In OAuth, the client, or third-party application, requests access to resources controlled by the resource owner and hosted by the resource server, and is issued a different set of credentials than those of the resource owner. Instead of using the credentials of the resource owner to access protected resources, the client obtains an access token, which is a string denoting a specific scope, lifetime, and other access attributes. Access tokens are issued to third-party clients by an authorization server with the approval of the resource owner. The client uses the access token to access the protected resources hosted by the resource server.

OAuth 2.0 is the latest OAuth protocol, and it is not compatible with an earlier version with OAuth 1.0. OAuth 2.0 allows ease of use for client application developers, while provides authorization flows for different types of client applications.

WebSphere Application Server supports OAuth 2.0, and plays a role as an OAuth service provider endpoint and an OAuth protected resource enforcement endpoint.

The OAuth standard specifications supported include:

• The OAuth 2.0 Authorization Framework
• The OAuth 2.0 Authorization Framework: Bearer Token Usage

Subtopics

• Summary of features inside WAS OAuth 2.0 services
  The following is a summary of features within WAS OAuth 2.0 services.
• OAuth 2.0 services
  WAS OAuth services include both OAuth authorization service and web resource authorization decision service.
• Invoking OAuth 2.0 service
  A registered OAuth client can invoke the WAS OAuth service authorization endpoint to request an authorization code. A registered OAuth client can also invoke the WAS OAuth service token endpoint to request an access token. The client then can use the access token to request protected web resources from WAS.
• Customize an OAuth provider
  The WAS OAuth service provider has plug-in points for customization. We can replace the default form login page for user authentication, or develop our own user consent form to collect client authorization data. WAS OAuth providers also allow customized post processing for major events in OAuth token issuing using mediators.
• SQL statements for persistent OAuth service
  WAS supports persistent OAuth 2.0 service by persisting OAuth tokens and clients in a database. With persistent OAuth 2.0 services, an authorized client can access OAuth 2.0 service after OAuth services are restarted.

Related information:

The OAuth 2.0 Authorization Framework
The OAuth 2.0 Authorization Framework: Bearer Token Usage

+

Search Tips   |   Advanced Search