I probably exaggerated a bit. It's not impossible but it is complex and
insecure for several reasons:
1) Such a super token would need to contain the union of all data and
permissions needed by all requested target services.
2) Not all services may by authorized to see all data contained in such
a super token (privacy!). So, you would need to built different
service-specific (encrypted) compartments within the token.
3) There are target-service-specific characteristics of such a token,
such as the audience and the signature. You would need to have such
attributes per service. Using public-key cryptography would relieve this
point but slow down processing.
4) You have to (somehow) prevent a target service from _abusing_ this
token to access another service for which the super token is valid for.
The only way I see is the usage of the client secret.
That's why I think, returning multiple tokens is much simpler.
regards,
Torsten.
Am 03.06.2010 20:10, schrieb Lukas Rosenstock:
Hi!
I'm curious why this is impossible. If access tokens are arbitrary
handles which are generated by the authorization server and
distributed to all resources, it doesn't make much difference whether
one or multiple are generated and in this case it would be better to
keep the load on the server rather complicating things for clients.
In the scenario (as you have mentioned) where access tokens are
self-contained and digitally signed, would it not be possible to
generate a "super token" which contains signatures from all resources?
I agree this token might be a bit lengthy, but is there any other
concern?!
Regards,
Lukas
2010/5/25 Torsten Lodderstedt<tors...@lodderstedt.net>:
As I said, every service in our setup needs another access token, with
different content, signed and encrypted with another shared secret. It is
technically impossible to create the super access token. Refresh tokens are
just handles representing the user's authorization and are used by the authz
server only. They therefore can represent any scope.
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
