Subject: Re: [OAUTH-WG] draft-ietf-oauth-revocation-03

From: Torsten Lodderstedt <[email-masked]>
Date: Tue, 25 Dec 2012 14:29:08 +0100

Hi Hannes,

thanks for providing feedback to the draft. I adopted the text you 
proposed with minor tweaks.

Does this work for your?

OAuth 2.0 allows deployment flexibility with respect to the style of 
access tokens. The access tokens may be self-contained so that an 
resource server needs no further interaction with an authorization 
server issuing these tokens to perform an authorization decision of the 
client requesting access to a protected resource. A system design may, 
however, instead use access tokens that are handles referring to 
authorization data stored at the authorization server. This consequently 
requires a resource server to issue a request to the respective 
authorization server to retrieve the content of the access token every 
time a client presents an access token.

While these are not the only options they illustrate the implications 
for revocation. In the latter case the authorization server is able to 
revoke an access token previously issued to a client when the resource 
server relays a received access token. In the former case some 
(currently non-standardized) backend interaction between the 
authorization server and the resource server may be used when immediate 
access token revocation is desired. Another design alternative is to 
issue short-lived access tokens, which can be refreshed at any time 
using the corresponding refresh tokens. This allows the authorization 
server to have a limit on the time revoked access tokens are in use.

Which approach of token revocation is chosen will depend on the overall 
system design and on the application service provider's risk analysis. 
The cost of revocation in terms of required state and communication 
overhead is ultimately the result of the desired security properties.

regards,
Torsten.

Am 26.11.2012 09:36, schrieb Hannes Tschofenig:
> Hi Torsten,
>
> thanks for the draft update. It looks good to me.
>
> I only have a minor wording suggestion for Section 3.
>
> Instead of
> "
>     Depending on the authorization server's token design, revocation of
>     access tokens might be a costly process.  For example, revocation of
>     self-contained access tokens requires (time-consuming) backend calls
>     between resource and authorization server on every request to the
>     resource server or to push notifications from the authorization
>     server to the affected resource servers.  Alternatively,
>     authorization servers may choose to issue short living access tokens,
>     which can be refreshed at any time using the corresponding refresh
>     tokens.  In this case, a client would revoke the refresh token and
>     access tokens issued based on this particular refresh token are at
>     most valid until expiration.  Whether this is an viable option or
>     whether access token revocation is required should be decided based
>     on the service provider's risk analysis.
> "
>
> what about the following text:
>
> "
> OAuth 2.0 allows deployment flexibility with respect to the style of access tokens. The access tokens may be self-contained so that an resource server needs no further interaction with an authorization server issuing these tokens to perform an authorization decision of the client requesting access to a protected resource. A system design may, however, instead use access tokens that are opaque to the resource server. This consequently requires a resource server to issue a request to an authorization server to retrieve the content of the access token every time a client presents an access token. While these are not the only options they illustrate the implications for revocation. In the latter case the authorization server is able to revoke an access token previously issued to a client when the resource server relays a received access token. In the former case some (currently non-standardized) back-end interaction between the authorization server and the resource server may be
>   used when immediate access token revocation is desired or another design alternative is to issue short-lived access tokens, which can be refreshed at any time using the corresponding refresh tokens. This allows the authorization server to have a limit on the time revoked access tokens are in use.
>
> Which approach of token revocation is chosen will depend on the overall system design and on the application service provider's risk analysis. The cost of revocation in terms of required state and communication overhead is ultimately the result of the desired security properties.
> "
>
> Ciao
> Hannes
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth