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

Lukas Rosenstock <lr@lukasrosenstock.net> Fri, 21 May 2010 16:54 UTC

Return-Path: <lr@lukasrosenstock.net>
X-Original-To: oauth@core3.amsl.com
Delivered-To: oauth@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16E373A7029 for <oauth@core3.amsl.com>; Fri, 21 May 2010 09:54:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.376
X-Spam-Level:
X-Spam-Status: No, score=-0.376 tagged_above=-999 required=5 tests=[AWL=-1.600, BAYES_50=0.001, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_66=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oHlKstnEpD0u for <oauth@core3.amsl.com>; Fri, 21 May 2010 09:54:30 -0700 (PDT)
Received: from mail-qy0-f200.google.com (mail-qy0-f200.google.com [209.85.221.200]) by core3.amsl.com (Postfix) with ESMTP id 7A0CF3A839C for <oauth@ietf.org>; Fri, 21 May 2010 07:26:57 -0700 (PDT)
Received: by qyk38 with SMTP id 38so1527655qyk.17 for <oauth@ietf.org>; Fri, 21 May 2010 07:26:48 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.229.182.145 with SMTP id cc17mr405273qcb.35.1274452007757; Fri, 21 May 2010 07:26:47 -0700 (PDT)
Received: by 10.229.250.202 with HTTP; Fri, 21 May 2010 07:26:47 -0700 (PDT)
In-Reply-To: <AANLkTikxD3jraqvG2IFmaSme0f1Q7NGPuQ3llqX3Ds5W@mail.gmail.com>
References: <4BEBDCFB.7090503@lodderstedt.net> <255B9BB34FB7D647A506DC292726F6E11263465727@WSMSG3153V.srv.dir.telstra.com> <AANLkTikxD3jraqvG2IFmaSme0f1Q7NGPuQ3llqX3Ds5W@mail.gmail.com>
Date: Fri, 21 May 2010 16:26:47 +0200
Message-ID: <AANLkTil8c6oLx-YpyQ57seoFpuZQ013hLpVWfdb8JWlM@mail.gmail.com>
From: Lukas Rosenstock <lr@lukasrosenstock.net>
To: "OAuth WG (oauth@ietf.org)" <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="0016364ecbf234a6f604871b7b74"
Subject: Re: [OAUTH-WG] in-app logout?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 21 May 2010 16:54:32 -0000

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 <dick.hardt@gmail.com>

> 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 <
> James.H.Manger@team.telstra.com> 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
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>


-- 
http://lukasrosenstock.net/