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

From: Torsten Lodderstedt <[email-masked]>
Date: Thu, 13 May 2010 13:05:31 +0200

OAuth currently focues on the issuance and usage of tokens.

What about refresh token revocation/deletion?

Several mobile apps today use long-living tokens as a means to log in to 
services. They typically also offer a button to log-off/log-out, which 
cause the app to delete the token from the device. From my point of 
view, it would be beneficially if the client could also discard the 
refresh token at the authorization server. Otherwise the token is still 
valid, which might be intransparent to the user.

I propose to add another request "delete" (or cancel or logoff or 
logout) which allows the client to delete the refresh token (and the 
end-user authorization it represents) at the authorization server.

Parameters: client_id, client_secret (optional), refresh_token

The request must check whether the token has been issued to the calling 
client. Otherwise the request is refused.

Thoughts?

regards,
Torsten.

---

From: "Manger, James H" <[email-masked]>
Date: Fri, 14 May 2010 00:10:21 +1000

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

---

From: Dick Hardt <[email-masked]>
Date: Sun, 16 May 2010 11:27:50 -0700

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:

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

---

From: "Manger, James H" <[email-masked]>
Date: Mon, 17 May 2010 10:20:58 +1000

Dick,

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

Defining refresh_token as a URI does not prevent it being a self-contained signed token.

The only limitation implied is a URI size limit. A few KB, however, is not that onerous a limit -- it is sufficient to hold a 4096-bit RSA signature with a couple of KB over for permissions etc.).

--
James Manger 

On Thu, May 13, 2010 at 7:10 AM, Manger, James H <[email-masked]> wrote:
Torsten,

---

From: Dick Hardt <[email-masked]>
Date: Sun, 16 May 2010 17:26:48 -0700

> The only limitation implied is a URI size limit. A few KB, however, is not that onerous a limit -- it is sufficient to hold a 4096-bit RSA signature with a couple of KB over for permissions etc.).

Agreed, a token could be a self contained token. A design objective was allowing existing systems to use existing tokens.

-- Dick

---

From: Yaron Goland <[email-masked]>
Date: Mon, 17 May 2010 16:45:48 +0000

Note that in some very popular browsers and some proxies the maximum safe URL size is more like 2k.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Dick Hardt
> Sent: Sunday, May 16, 2010 5:27 PM
> To: Manger, James H
> Cc: OAuth WG ([email-masked])
> Subject: Re: [OAUTH-WG] in-app logout?
> 
> 
> > The only limitation implied is a URI size limit. A few KB, however, is not that
> onerous a limit -- it is sufficient to hold a 4096-bit RSA signature with a couple
> of KB over for permissions etc.).
> 
> Agreed, a token could be a self contained token. A design objective was
> allowing existing systems to use existing tokens.
> 
> -- Dick
>

---

From: "Manger, James H" <[email-masked]>
Date: Tue, 18 May 2010 09:31:29 +1000

Yaron,

> Note that in some very popular browsers and some proxies the maximum safe URL size is more like 2k.

2KB is sufficient for a 4096-bit RSA signature = 4096 / 8 * 4 / 3 = 683 base64 chars -- with 1.3KB over for permissions etc.

---

From: "Manger, James H" <[email-masked]>
Date: Wed, 19 May 2010 09:56:14 +1000

Dick,

I may have misinterpreted you design objective of "allowing existing systems to use existing tokens" as meaning: the refresh_token field shouldn't be defined as a URI as some existing tokens are too big to fit in URIs.

If the size of existing tokens is an issue then the user-agent flow will not work -- since it returns an access_token (and, optionally, a refresh_token as well) in a URI fragment.

An existing token always needs to be extracted from a request: typically from a FORM-encoded string of parameters. Defining refresh_token as a URI doesn't really change this: an existing token can still be extracted from a query parameter in such a URI. I believe this still meets a design objective of allowing existing systems to use existing tokens.

So I suggest renaming refresh_token to, say, token_uri, and defining it to be a URI.

P.S. An authz service could even choose the following so a refresh request looks much like the current draft if it really needed that.
  "token_uri": "/token?refresh_token=8xLOxBtZp8"

-- 
James Manger

-----Original Message-----
From: Dick Hardt [mailto:[email-masked]] 
Sent: Monday, 17 May 2010 10:27 AM
To: Manger, James H
Cc: OAuth WG ([email-masked])
Subject: Re: [OAUTH-WG] in-app logout?

-- Dick

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Manger, James H
Sent: Friday, 14 May 2010 12:10 AM
To: Torsten Lodderstedt; OAuth WG ([email-masked])
Subject: Re: [OAUTH-WG] in-app logout?

Torsten,

--
James Manger

---

From: Chasen Le Hara <[email-masked]>
Date: Thu, 20 May 2010 21:05:21 -0700

> painkiller and will fall by the wayside unless the security conscience rally

I’d like to put in another vote for this mechanism.

I’m about to add a “in-app logout” to an iPhone app that uses OAuth; while I
can delete the token from the device, a standard way for deleting the token
from the web service would be helpful in preventing future uses of the token
(for example, if the device is restored from a backup and the token was
stored in the backup files).
-Chasen

---

From: Hubert Le Van Gong <[email-masked]>
Date: Fri, 21 May 2010 09:35:37 +0200

I agree token management is important. It actually can (and sometimes
must) go farther than token deletion/revocation. For instance, adding the
possibility for the resource owner (or others with appropriate rights) of
"inspecting" released tokens etc. Kind of like what UMA is getting at.

At the protocol level we already have a request message to obtain a
token, it would seem logical to have one to delete/revoke it.

In our OAuth implementation we adopted a RESTful approach where
tokens were represented as URIs. In that case token management
(which ) is "just" a matter of using standard HTTP operations. However,
there are security issues that needs to be dealt with in terms of who
can perform such operation. This is especially the case with large
deployments or when the OAuth protocol is only one part of a more
complex product.
All this to say that I don't think HTTP delete is the general solution
for this and would advocate for a Delete_token request.

Hubert

---

From: Lukas Rosenstock <[email-masked]>
Date: Fri, 21 May 2010 16:26:47 +0200

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

-- 
http://lukasrosenstock.net/

---

From: Allen Tom <[email-masked]>
Date: Fri, 21 May 2010 08:47:20 -0700

+1

There are many examples in production of token authentication schemes that
have a ³revoke token² API for clients to voluntarily revoke their own
credentials.  

Examples:

Google¹s AuthSubRevokeToken:
http://code.google.com/apis/accounts/docs/AuthSub.html#AuthSubRevokeToken

OAuth Session Extension (for OAuth 1.0a):
http://oauth.googlecode.com/svn/spec/ext/session/1.0/drafts/1/spec.html#anch
or10

Allen

On 5/20/10 9:05 PM, "Chasen Le Hara" <[email-masked]> wrote:

> I¹d like to put in another vote for this mechanism.
> 
> I¹m about to add a ³in-app logout² to an iPhone app that uses OAuth; while I
> (for example, if the device is restored from a backup and the token was stored
> in the backup files).
> -Chasen
> 
>

---

From: Beau Lebens <[email-masked]>
Date: Fri, 21 May 2010 10:05:08 -0700

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

---

From: Hubert Le Van Gong <[email-masked]>
Date: Sat, 22 May 2010 09:13:19 +0200

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

---

From: Torsten Lodderstedt <[email-masked]>
Date: Wed, 26 May 2010 20:26:18 +0200

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.

> On Fri, May 21, 2010 at 7:05 PM, Beau Lebens<[email-masked]>  wrote:
>    
>> On Friday, May 21, 2010, Lukas Rosenstock<[email-masked]>  wrote:
>>      
>>> 2010/5/16 Dick Hardt<[email-masked]>
>>>
>>> On Thu, May 13, 2010 at 7:10 AM, Manger, James H<[email-masked]>  wrote:
>>> Torsten,
>>>
>>>

---

From: Igor Faynberg <[email-masked]>
Date: Wed, 26 May 2010 14:52:56 -0400

+1 on the support.

Torsten, I just wonder if you see this as (possible a part of ) a 
single-sign off method?

Igor

Torsten Lodderstedt wrote:
> 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 
>>>> 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.
>>>> 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
>>>>
>>>> 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,
>>>>
>>>>       
>>>> 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).
>>>>
>>>> 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.
>>>> 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