IMHO this would look more like a hack than proper protocol design. We need a delete/revoke operation that's the pendant to the other token operations (i.e. crud ops).
Hubert On Fri, May 21, 2010 at 7:05 PM, Beau Lebens <[email protected]> wrote: > Could this just be implemented through support for a scope change > where scope=none or revoke or something? > > On Friday, May 21, 2010, Lukas Rosenstock <[email protected]> wrote: >> Why not simply add this functionality to the token endpoint?The same place >> that was used to fetch the access token first or refresh it could be used to >> revoke the same token with another request. The only requirement would be to >> define something like type=revoke. >> I feel that is much easier than making the token a URL which supports DELETE. >> However, any mechanism will break implementations that rely on minimal or no >> communication between authorization server and protected resource, because >> all protected resources have to be informed. >> >> Regards, Lukas >> >> 2010/5/16 Dick Hardt <[email protected]> >> >> James: An important capability of the refresh token is that it *can* be a >> self contained token in that is not an id, but a signed token that can be >> examined and acted upon on presentation. >> Torsten: enabling a client to revoke a refresh token looks like a useful >> mechanism. I anticipate it will be viewed as a vitamin feature rather than a >> painkiller and will fall by the wayside unless the security conscience rally >> to have it included. >> >> >> -- Dick >> >> >> On Thu, May 13, 2010 at 7:10 AM, Manger, James H >> <[email protected]> wrote: >> Torsten, >> >>> What about refresh token revocation/deletion? >> >> HTTP already has a method to do this: DELETE >> It just needs each token to have a URI. >> >> Tokens (almost) already have URIs -- its just not immediately obvious >> because the URI has to be built from a common token endpoint and a >> refresh_token. >> >> I think it would improve the spec if refresh_token was renamed to, say, >> token_id; and its value defined as a URI (which can be a relative URI so the >> string may not need to change at all). >> >> To refresh a token you POST to the token's URI. >> To delete a token you send a DELETE request to the token's URI. >> >> It doesn't cause major changes, but there are some benefits. >> It is a more web-style design. >> It leaves only 1 type of token in the spec -- an access token -- which >> simplifies the text and aids understanding. >> There are no arguments about length, allowed chars etc because it is a URI >> -- a well-known type, often with native support. >> Its obvious how to delete the token as there is a standard HTTP method >> DELETE to apply to the token URI. >> >> If a particular service supported an additional way to delete items in its >> API (eg POST with a method=delete query parameter) that could apply to the >> OAuth part as well. >> >> -- >> James Manger >> _______________________________________________ >> OAuth mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> >> _______________________________________________ >> OAuth mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> >> -- >> http://lukasrosenstock.net/ >> >> > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
