Consider the following distributed system that uses OAuth 2.0 for authorization and OpenID 2.0 for authentication.

Where
- RS1, RS2 and RS3 are “Resource Servers” (aka three different REST APIs)
- APP1 and APP2 are clients
- AS is an “Authorization Server” for managing OAuth tokens
- OPENID is an OpenID 2.0 provider.
APP2 uses RS1, which in turn is uses resources on RS2 and RS3. There is a trust between RS1, RS2, RS3, APP2, AS and OPENID as they are developed by the same company (but different teams). When a user access APP2 for the first time, APP2 is automatically authorized to access resources on RS1, RS2 and RS3 on behalf of the user.
APP1 uses resources in RS2, which in turn uses resources in RS3. APP1 is a third party website which is not trusted and a user needs to explicitly authorize APP1 to get access to resources on RS2 and RS3.
Most examples regarding OAuth 2.0 shows the communication between a single resource and authorization server and how to request, issue and manage the tokens.
How would one secure this environment using OAuth 2.0? For example, would APP2, RS1 and RS2 have their own client identifier and client secret (as they are all “clients” to another server)? If so, how would one issue access tokens for RS1 when it tries to access resources on RS2 and RS3 for the first time in the middle of another request (coming from APP2)?
I already have AS, OPENID, APP2 and RS1, which was developed using ASP.NET MVC 3, WCF 4 and DotNetOpenAuth 4. I’m trying to introduce RS2, RS3 and APP1 into the system but struggle to figure out how authorization between the resource servers and clients will work. Everything runs under IIS 7.5 and HTTPS.
I assume APP2 is a web app, since any other type of app can’t be “trusted” as soon as it is downloaded to the client machine.
I think you’re right on as far as authenticating your trusted apps to each other using client credentials. DotNetOpenAuth 4.0 beta doesn’t yet support client credentials but that’s hopefully coming in the next week or so.
In OAuth 2, client credentials would be built into your trusted clients. These credentials would be exchanged at runtime for refresh and access tokens that would be sent to the resource servers. You apply the access token to each outbound HTTP request using a DNOA API that will automatically renew any expired access tokens by another request to the authorization server.