Child pages
  • Experimental AM Protocol
Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »

This is my initial take on the problem on how to do distributed authorization. It is not compatible with the work done in the UMA Workgroup at the moment.

Motivation

The motivation for creating this proposal was an attempt to find a simple solution for mainly solving the Distributed Authorization Scenario described in the UMA Workgroup. It is also an attempt to reuse more of OAuth than the initial protocol sketch of ProtectServe did back then. Moreover it is an attempt to create several small specifications than one big one. For instance all the mechanics of how to do terms and policies is out of scope for the core protocol.

The main idea

In the IETF version of OAuth the initial OAuth specification will be divided into at least two: One is describing how to perform a authorized request to a protected resource and the other is describing one possible way of obtaining the OAuth token (by using the redirect mechanism).

In this specification we will use plain OAuth to perform an authorized request from a Requester to a Host. The only difference will be on how the Requester obtains a token for being used with the Host.

This is done by a chained token transfer. For this the Requester calls the Token Requester API on the Authorization Manager (AM) and the AM in turn calls the Token Requester API of the Host. The Host then returns a token (maybe with prior checks) to the AM which in turn is given to the Requester which then can perform the actual call with it.

Here is an overview of the process:

Roles

The following roles are defined:

  • Requester is performing authorized requests to a Host (in OAuth terms it's a client)
  • Host is the component which hosts a resource which a Requester wants access to (in OAuth terms it's a server)
  • Authorization Manager (AM) is the component in the middle which is capable of negotiating between Requesters and Hosts and which can give out tokens. It might also be the central point for managing terms and policies in the future.
  • No labels