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
