...

Each Requester which wants to use the AM's services need to register with the AM. This is usually triggered by the user on the Requester who wants the Requester to be able to access the user's resources. For instance this can be triggered by a user signing up with the Requester and trying to provide the Requester with access to all it's life-streaming services such as Twitter or Facebook (which would be the Hosts then).

The flow is a normal 3-legged OAuth Redirection-Based Authorization workflow as described in section 2 of the IETF OAuth specification. If everything is successful the Requester posses an OAuth Token for calling the AM Requester API on the AM.

AM - Host Registration

This step is usually done before the Requester registration. Here the user signs up to a new service and wants the authorization decisions being handled by an Authorization Manager. Those services could be Facebook or Twitter and again they are Hosts in this scenario.

In order to do that the AM initiates another 3-legged OAuth Redirection-Based Authorization workflow for each of them. The result is that the AM then has an OAuth token for each of these Hosts for calling the Host Requester API. Note that this is not the same as the protected resource a Requester might want to call.

The main flow

Now the Requester might want to post something on the Hosts of that user. It needs an OAuth Token of the Host to do so. Usually this is obtained by a 3-legged-OAuth flow from Requester to Host. In this case though no such thing is needed. Instead the following is happening:

1. The Requester uses the OAuth token of the AM obtained above to call the AM Requester API.
2. The AM in turn will call the Host Requester API of the Host in question
3. The Host returns a token for accessing the protected resource to the AM
4. The AM passes this token to the Requester
5. The Requester now can access the protected resource on the Host.

Open Questions