Hi Adam, Justin may chime in at some point about this, but he has a draft out that I think addresses what you (and James) are looking for: http://tools.ietf.org/html/draft-richer-oauth-chain-00. He's posted it to the working group once or twice to get feedback and called a meeting about it at IIW last week, but so far he hasn't found many people who actually agree this is a valuable addition (at least, that has been my read of the room the times its been discussed).
Take a look at the draft and see if it looks like it's headed in the right (or wrong) direction - feedback would be great. --Amanda ________________________________ From: [email protected] [[email protected]] on behalf of Lewis Adam-CAL022 [[email protected]] Sent: Friday, November 02, 2012 6:23 PM To: Manger, James H Cc: [email protected] Subject: Re: [OAUTH-WG] access tokens & refresh tokens of different scopes Hi James, Wish I were around at the time that was discussed, but doubt my presence would have tipped the scales :) You actually make another point that I would find very valuable and that is to obtain multiple access tokens (of different scopes) in a single request. My use cases will have a client accessing at least three different resource servers on behalf of the user. Using vanilla OAuth I have to go through the following OAuth round trips (not including primary authentication to the AS): 1. Authorization request / authorization response (with scope=rs1+rs2+rs3) 2. Access token request / access token response (gives me AT with scope=rs1+rs2+rs3 and RT). I need to discard the AT because its scope is too promiscuous to send to any given RS. 3. Access token request (using RT) with scope=rs1 / access token response (AT for rs1) 4. Access token request (using RT) with scope=rs2 / access token response (AT for rs2) 5. Access token request (using RT) with scope=rs3 / access token response (AT for rs3) Five round trips is going to kill me. And my guess is that we will add more resource servers in the future to that this client will access making it even worse. If there was a way to get all three down-scoped access tokens + the fully scoped refresh token in step 2, then this would be highly efficient. I’m normally a consumer of IETF efforts rather than a contributor, but I’d be interested in working on this if the WG agrees it’s worthwhile. It seems at least you and Torsten agree in principle … what level of critical mass is required to get something moving? adam From: Manger, James H [mailto:[email protected]] Sent: Wednesday, October 31, 2012 8:01 PM To: Lewis Adam-CAL022 Cc: "WG <[email protected]>"@il06exr01.mot.com Subject: RE: [OAUTH-WG] access tokens & refresh tokens of different scopes Adam, I’ll chime in and say you have a reasonable requirement (getting tokens with different scopes (for different resource servers) efficiently). Over the last few years there have been a number of proposals for OAuth to support this (by allowing an authorization server to return multiple tokens, each with their own scope). Unfortunately, despite some support, the proposals were rejected for the core spec. There was strong resistance to any complexity that wasn’t absolutely necessary for the basic use case — and flexibility for likely (though maybe niche) scenarios such as yours was not sufficient motivation. As it turns out, one significant early use of OAuth2 does need an extra token (the ID token in OpenID Connect). That is being supported with some additions to OAuth2 that are highly specific to OpenID Connect so it does not help your requirement. -- James Manger From: [email protected] [mailto:[email protected]] On Behalf Of Lewis Adam-CAL022 Sent: Thursday, 1 November 2012 4:01 AM To: [email protected] Subject: [OAUTH-WG] access tokens & refresh tokens of different scopes I have a use case where I would like to request both an access token and a refresh token, but I would like the access token to have a scope less than that of the refresh token. It is standard OAuth behavior for using the refresh token to request additional access tokens (of equal or lesser scope) but the first access token that comes back always has the “master scope” of the refresh token. For various security concerns, I always want my access tokens to be of a stricter scope that the refresh token. For example, consider the scenario of a structured (JWT) access token that does not require the RS to call back to the AS introspection endpoint. Following typical OAuth guidance, it is best practice to use short lived access tokens with long lived refresh tokens. But I’d rather a compromised access token not compromise access to ALL my resource servers. Using the existing standard I could simply destroy the first access token when it is received and then request another of lesser scope using the refresh token, but now I’ve just wasted a round trip over the air, consuming bandwidth and adding latency to the end user experience. Is there anybody in the working group that feels this would be valuable? adam
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
