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 b
e
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 protected]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
