Re: [OAUTH-WG] in-app logout?

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
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth