Hi Marius,
Am 07.04.2010 00:39, schrieb Marius Scurtescu:
On Tue, Apr 6, 2010 at 10:00 AM, Torsten Lodderstedt
<[email protected]> 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."
The idea of acquiring downsized access tokens is very interesting from a
security standpoint. A client could obtain a token with the least
privileges set required for the transaction it is about to perform thus
reducing the impact if a token gets revealed.
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.
You are right, this is an alternative option. We don't go that way
because we don't want the clients to know the internal structure of our
services. Therefore the first service (or any other service in the call
chain) is exchanging the tokens. This token exhange is more a technical
"claim transformation" than a scope reduction/transformation. As I
described, trust between authz server and service ist based on shared
secrets (as in Kerberos) so any piece data intended for a particular
service must be encrypted/HMACd with the corresponding secret. Moreover
(and most important), the token payload is different. That's why we
can't use the same token for the whole call chain.
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.
That's true.
regards,
Torsten.
Marius
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
