What if you had a supertoken that was only good for getting subtokens? In other words, only the AS knows about the supertoken (a refresh token, perhaps?), and it allows you to get sub-tokens using the refresh flow to access each of the different services. Then you could grab as many different tokens with individual scopes as you want.
This could also be an application for the rescoping proposal, which I'm liking more now. I've had some colleagues ask me about redelegation in OAuth2, and I'm starting to think that the rescoping methods might be the right answer there. I see Torsten's problem as something similar: you get a token that's good for getting other tokens but not for accessing protected resources (the refresh token). You then use this token that has a "global" scope to request tokens with more directed scopes, which can have all of the per-service signed characteristics in the token itself that Torsten was talking about. Would that work? -- Justin On Thu, 2010-06-03 at 14:27 -0400, Torsten Lodderstedt wrote: > 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 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
