This is exactly my contention with using DELETE: it's specified[1] as deleting the resource identified by the URI, and it's not meant as way to determine intended action in a higher-level API. Like PUT, it's there for using HTTP as a uri-addressable document store. I'm also not convinced it's going to be as well-supported across client libraries as GET and POST will be, but I can't confirm that in practice as I don't remember ever using the DELETE method by hand. I'm also not in favor of requiring all tokens be URL-addressable. I'd much rather see us use a separate delete/revoke method. Perhaps in parallel with how the rescope is written in -08 (which structure I'm mostly happy with, btw) we can have an optional argument that says "please trash this token". Also, it seems we should be able to revoke both refresh and access tokens by presenting them to the token endpoint.
I can see this kind of API call as something that some providers are going to offer anyway, so it should be part of OAuth so that everyone does it the same way. This may be another candidate for "just throw it in an extension", but we seem to be collecting quite a few of those lately. :) -- Justin [1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html On Tue, 2010-06-15 at 00:24 -0400, Manger, James H wrote: > > Since refresh token is only issued to clients capable of directly > > interacting with the authorization server, is there a reason why the > > endpoint cannot use DELETE instead of a POST with a parameter? > > > > DELETE /token HTTP/1.1 > > Host: server.example.com > > Content-Type: application/x-www-form-urlencoded > > > > > > grant_type=refresh_token&client_id=s6BhdRkqt3&client_secret=8eSEIpnqmM&refresh_token=n4E9O119d > > > > This looks like an elegant way of doing things. I'm not sure about using > > the token endpoint for this, but that's a separate issue. > > > The DELETE method deletes the resource identified by the URI. I don't think > it is usual to have any body with a DELETE. Any intermediaries seeing the > DELETE will mark as stale any cached responses indexed by the URI -- they > will not look in the body. > > In short, a more web-style approach is to give each token its own URI and > DELETE that. > > DELETE /token?refresh_token=n4E90119d HTTP/1.1 > Authorization: BASIC czZCaGRSa3F0Mzo4ZVNFSXBucW1N > > -- > 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
