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

[Eran Hammer-Lahav <[e-mail]>]

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:[e-mail]]
> Sent: Monday, June 14, 2010 11:30 AM
> To: Eran Hammer-Lahav
> Cc: OAuth WG ([e-mail])
> 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:[e-mail]]
> >> Sent: Wednesday, May 26, 2010 11:26 AM
> >> To: Eran Hammer-Lahav
> >> Cc: OAuth WG ([e-mail])
> >> 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<[e-mail]>   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<[e-mail]>
> >>>>
> >> 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<[e-mail]>
> >>>>>
> >>>>> 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<[e-mail]>   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
> >>>>> [e-mail]
> >>>>> https://www.ietf.org/mailman/listinfo/oauth
> >>>>>
> >>>>>
> >>>>>
> >>>>> _______________________________________________
> >>>>> OAuth mailing list
> >>>>> [e-mail]
> >>>>> https://www.ietf.org/mailman/listinfo/oauth
> >>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>> http://lukasrosenstock.net/
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>> _______________________________________________
> >>>> OAuth mailing list
> >>>> [e-mail]
> >>>> https://www.ietf.org/mailman/listinfo/oauth
> >>>>
> >>>>
> >>>>
> >>> _______________________________________________
> >>> OAuth mailing list
> >>> [e-mail]
> >>> https://www.ietf.org/mailman/listinfo/oauth
> >>>
> >>>
> >>
> >