On Tue, Apr 6, 2010 at 10:00 AM, Torsten Lodderstedt <tors...@lodderstedt.net> wrote: > Hi all, > > here at Deutsche Telekom, we see the need for a flow supporting the exchange > of access tokens for one service into access tokens for another service. > > The scenarios is as follows: In the context of mobile applications, we > employ multi-layered architectures of personalized web services. The first > layer typically exposes an API optimized for the flows of a particular > application. This layer's business logic is built on top of other web > services and so on. We use self-contained bearer tokens carrying id's, > attributes and permissions. Each of the web services involed has a trust > relationship with our authorization server based on shared secrets. Every > web service requires a different token with different claims (id, > permissions, attributes) and signature (HMAC). > > The flow is as follows: > > 1) The client acquires a token for the first service eather by > username/password authentication or web-based authorization flow. > > 2) The client sends a request (including the access token) to the first web > service. > > 3) Access control and some business logic is executed based on the token > contents. Afterwards, the first service determines that it needs > to call another services (second web service) on behalf of the user. > > 4) It requests the issuance of a new token for the second service from the > authorization server based on the original token sent by the client. > > 5) The authorization server issues a new token carrying the claims need by > the second web service and digitally signs the token > with the respective shared secret. It also encrypts the token content in > order to prevent the first web service from eavesdropping the users data > intended for the second service only. > > 6) The first web service uses the token to invoke the second web service. > > ... > > Does anyone else see the need for such a flow?
I think I suggested something like that on the scope thread: "Things can get even more complicated. When the user grants access for the client, the approval page should list all the scopes the client is requesting. This is the set of scopes needed by the client for *all* the API calls. Each API will need a subset of this approved, larger set. With that in mind, it would be useful to be able to down-scope access tokens when using the refresh token, this way the client can send the smallest set of scopes with each API call." In your example, instead of having the first service request a new token for the second service, step 4, I think the client should do that and pass the second token as an argument in the API call. Basically the client requests a refresh token with largest set of permissions and then it uses the refresh token flow to get lower-permission access tokens as needed. The first service can ask for a second token only if the set of permissions is a sub-set of the one it received, otherwise it has not authority to do that. Marius _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
