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