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

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 14 Jun 2010 10:10:47 -0700

Not so much text as details.

Does revoking the refresh token also revokes any access token issued with it?
Do we need a way to revoke other authorization grants, such as a verification code?
Do we need a way to revoke an individual access token?
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?

EHL

> -----Original Message-----
> From: Torsten Lodderstedt [mailto:[email-masked]]
> Sent: Wednesday, May 26, 2010 11:26 AM
> To: Eran Hammer-Lahav
> Cc: OAuth WG ([email-masked])
> 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-masked]>  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-masked]>
> 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-masked]>
> >>>
> >>> 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-masked]>  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-masked]
> >>> https://www.ietf.org/mailman/listinfo/oauth
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> OAuth mailing list
> >>> [email-masked]
> >>> https://www.ietf.org/mailman/listinfo/oauth
> >>>
> >>>
> >>>
> >>> --
> >>> http://lukasrosenstock.net/
> >>>
> >>>
> >>>
> >> _______________________________________________
> >> OAuth mailing list
> >> [email-masked]
> >> https://www.ietf.org/mailman/listinfo/oauth
> >>
> >>
> > _______________________________________________
> > OAuth mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/oauth
> >
>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Mon, 14 Jun 2010 20:30:18 +0200

> 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…

I think both options are reasonable.

regards,
Torsten.

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 14 Jun 2010 13:56:35 -0700

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

> Sent: Monday, June 14, 2010 11:30 AM
> To: Eran Hammer-Lahav
> 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.
> 
> I don't see a need. Verification codes should expire very quickly and are one-
> time use only.
> 
> 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?
> >
> 
> >> 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
> >>>
> >>>
> >>>
> >> 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.
> >>
> >> minimal or no communication between authorization server and
> >> protected resource, because all protected resources have to be informed.
> >>
> >>>>> Regards, Lukas
> >>>>>
> >> self contained token in that is not an id, but a signed token that
> >> can be examined and acted upon on presentation.
> >>
> >> 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
> >>>>>
> >>>>>
> >> 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).
> >>
> >> API (eg POST with a method=delete query parameter) that could apply
> >> to the OAuth part as well.
> >>
> >>>>> --
> >>>>> James Manger

---

From: "Manger, James H" <[email-masked]>
Date: Tue, 15 Jun 2010 14:24:01 +1000

> 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

---

From: Justin Richer <[email-masked]>
Date: Tue, 15 Jun 2010 12:12:50 -0400

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