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

["Manger, James H" <[e-mail]>]

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:[e-mail]] 
Sent: Monday, 17 May 2010 10:27 AM
To: Manger, James H
Cc: OAuth WG ([e-mail])
Subject: Re: [OAUTH-WG] in-app logout?


On 2010-05-16, at 5:20 PM, Manger, James H wrote:

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

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

-- Dick


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

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