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. EHL > -----Original Message----- > From: Torsten Lodderstedt [mailto:[email protected]] > Sent: Monday, June 14, 2010 11:30 AM > To: Eran Hammer-Lahav > Cc: OAuth WG ([email protected]) > Subject: Re: [OAUTH-WG] in-app logout? > > > > Am 14.06.2010 19:10, schrieb Eran Hammer-Lahav: > > Not so much text as details. > > > > Does revoking the refresh token also revokes any access token issued with > it? > > > no (or optionally). It's not easy to implement in conjuction with self- > contained tokens. I would prefer to use short living access tokens instead. > > > Do we need a way to revoke other authorization grants, such as a > verification code? > > > > I don't see a need. Verification codes should expire very quickly and are one- > time use only. > > > Do we need a way to revoke an individual access token? > > > > I currently don't see a need. I would prefer to use short living access tokens > instead. > > > Does revoking means the end-user has to grant authorization again > (explicitly)? Or just the refresh token and the server may issue another > refresh token to the client based on some client-end-user authorization > mapping? > > > > I think both options are reasonable. > > regards, > Torsten. > > > EHL > > > > > >> -----Original Message----- > >> From: Torsten Lodderstedt [mailto:[email protected]] > >> Sent: Wednesday, May 26, 2010 11:26 AM > >> To: Eran Hammer-Lahav > >> Cc: OAuth WG ([email protected]) > >> Subject: Re: [OAUTH-WG] in-app logout? > >> > >> Hi Eran, > >> > >> in my perception, there is some support on the list for having a > >> request to revoke refresh tokens. Will you add such a request to the > >> specification? Do you need a text proposal? > >> > >> regards, > >> Torsten. > >> > >> > >>> 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 > >>> > >>> > >> > > _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
