Share via


Calling REST Service On Behalf Of End User - OAuth 2.0 Delegation

Back to [[Windows Azure Active Directory Solutions For Developers]] 

Scenario

In this scenario you are developing an application where the end user consumes a web site which needs to access services that require authentication for the end user and in turn apply authorization logic for authenticated users. 

  • Internet facing web applications.
  • Heterogeneous browsers running on heterogeneous client machines possessed by end users.
  • Each application manages identities independently.
  • Each application developed using different development technologies (.Net, Java, PHP, etc.).
  • Each service exposes its functionality via RESTful web services endpoints.
  • Aggregator solution is a web application developed using Microsoft’s .Net technology.
  • There are significant challenges (technological or legal) to synchronize identities between the applications.
  • The aggregator application needs to reuse current identification and authentication processes without compromising it.

Solution Approach

Microsoft Windows Identity Foundation OAuth Helper Components offer implementation of building blocks to enable end user delegated authorization for RESTful architectures. It follows OAuth 2.0 protocol recommendations. 

  • OAuth client. OAuth client resides on 3rd party aggregating web site requesting to work on behalf of the end user. Responsible for requesting an OAuth token from Authorization Server and submitting the token to Protected Resource along with actual request for data.
  • Authorization Service.  Authorization Service is responsible for accepting requests from the OAuth 2.0 clients for authorization and refresh tokens. From OAuth 2.0 specification: “A server capable of issuing tokens after successfully authenticating the resource owner and obtaining authorization. The authorization server may be the same server as the resource  server, or a separate entity.” ACS plays the role of Authorization Service.
  • Resource protection component. Resource protection component resides on Protected Resource side and responsible for parsing incoming tokens. The outcome of the parsing the token is either denying or granting access to the Protected Resource requested by the aggregator application on behalf of the end user.
  • UI consent pages. UI consent pages is responsible for accepting end user’s credentials for submitting it to original identity management system, and for asking user’s consent for using his or her information from the original system. 

Analysis

Refer to the whitepaper available as part of the available download in resources section.

How To's

Code Samples

Resources