I believe my use case can be addressed in OAuth 2.0 it self with a new grant type or in UMA.
Let me break down this in to four phases.
1. Client registers with the Resource Server via Authorization Server
2. Resource Owner grants access to a selected Client.
3. Client gets access_token from the Authorization Server.
4. Client accesses the protected resource on behalf of the Resource Owner.
Let's dig deep.
1. Client registers with the Resource Server via Authorization Server.
This is the a normal OAuth request with any of the defined grant types with the scope resource_owner_initiated.
At the time of Client registration on the Resource Server, Client will be redirected to his Authorization Server.
In return Resource Server gets an access_token along with the client_id. Now Resource Server has a set of registered Clients with corresponding access_tokens.
2. Resource Owner grants access to a selected Client.
Resource Owner logs in to the Resource Server and he can see all registered Clients with the Resource Server.
Resource Owner picks a Client.
Let's say the client_id we got was Foo from Step-1, along with the access_token.
Now, the Resource Server will redirect the Resource Owner to the Authorization Server.
GET /authorize? grant_type=resource_owner_initiated&client_id=Foo&scope=Bar
Host: server.example.com
If the above is successful then the Authorization Server will send the following to the Resource Server.
HTTP/1.1 200 OK
After this step completed, Authorization Server will create an access_token for the Client - to access the a Protected Resource on behalf of the Resource Owner .
3. Client gets access_token from the Authorization Server.
Client should be able to get all the resource owner delegated access_tokens for him or a single one by specifying the resource owner Id.
To get all the delegated access_tokens - from the Client to the Authorization Server.
POST /token HTTP/1.1
Host: server.example.com
Authorization: Basic XfhgFgdsdsdkhewe
Content-Type: application/x-www-form-urlencoded
grant_type=resource_owner_initiated
Response from the Authorization Server to the Client.
HTTP/1.1 200 OKContent-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache
{
"delegated_tokens" : [
{ "access_token":"2YotnFZFEjr1zCsicMWpAA",
"token_type":"example",
"expires_in":3600,
"refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",
"resource_owner_id":"Bob"
},
{ "access_token":"2YotnFZFEjr1zCsicMWpAA",
"token_type":"example",
"expires_in":3600,
"refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",
"resource_owner_id":"Tom"
}
]
}
To get a single delegated access_token - from the Client to the Authorization Server.
POST /token HTTP/1.1
Host: server.example.com
Authorization: Basic XfhgFgdsdsdkhewe
Content-Type: application/x-www-form-urlencoded
grant_type=resource_owner_initiated&resource_owner_id=Bob
Response from the Authorization Server to the Client.
HTTP/1.1 200 OKContent-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache
{
"access_token":"2YotnFZFEjr1zCsicMWpAA",
"token_type":"example",
"expires_in":3600,
"refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",
"resource_owner_id":"Bob"
}
4. Client accesses the protected resource on behalf of the Resource Owner.
This is normal OAuth flow. Client can now access the Protected Resource with the access_token.