Re: [OAUTH-WG] survey: token revocation design options

[Torsten Lodderstedt <[e-mail]>]

  Igor,

1c does not further narrow down the character set for tokens. It instead 
establishes an additional (URL-safe) id. That way no change is needed on 
existing token formats and the existing protocol definition. This could 
be combined with 1a or 1b but why? To cope with URL length restrictions?

regards,
Torsten.

Am 17.08.2010 00:22, schrieb Igor Faynberg:
> Torsten,
>
> This really captures everything!
>
> Option 1a  is the best fit for me (and this is really only my personal 
> opinion). (Incidentally, 1c, looks to me like it is not a separate 
> option as it could be implemented along both 1a and 1b. I suspect I 
> missed something; if not, I would change my vote to 1c or 1a+1c.)
>
> Looking forward to seening the new I-D,
>
> Igor
>
> Torsten Lodderstedt wrote:
>> Hi all,
>>
>> I intend to submit a I-D for token revocation. Based on previous 
>> discussions on the mailing list and here at Deutsche Telekom, I see a 
>> couple of design options. I would like to share those options with 
>> the WG and try to reach consensus on a single option before investing 
>> the time to write the I-D.
>>
>> 1) HTTP Delete on tokens endpoint
>>
>> DELETE seems a natural way for revoking (deleting) tokens. Although 
>> the HTTP spec is a bit vaque in this concern, current practice 
>> prohibits a body for DELETE requests. So the token must be addressed 
>> by the request's URI. Lets assume the token is passed as URI query 
>> parameter as follows:
>>
>>  DELETE /tokens?refresh_token=8xLOxBtZp8&&&# HTTP/1.1
>>  Authorization: BASIC czZCaGRSa3F0Mzo4ZVNFSXBucW1N
>>
>> But is it advisable to pass tokens as URI query parameters? The 
>> current character set definition for access tokens (§5.1.1) is not 
>> URL-safe since it includes URI reserved characters (e.g. '/'). 
>> Additionally, there is no definition of a refresh tokens character 
>> set. So compliant authorization servers could issue tokens, which 
>> cannot be safely passed as URI query parameters.
>>
>> Note: As an additional challenge, self-contained tokens can be very 
>> large. So passing them as URI parameter may exceed URL length limits.
>>
>> I see the following alternatives to cope with the encoding problem:
>>
>> a) Force usage of a URL-safe character set for access and request 
>> tokens.
>> - rather restrictive, will most likely collide with existing token 
>> formats
>> - does not solve URL length problem
>>
>> b) Force base64-URL-safe encoding for all tokens on transit.
>> - does not solve URL length problem
>> - significant API change
>>
>> c) Authorization servers supporting revocation may additionally issue 
>> a URL-safe token id in the access token response. This id is used to 
>> reference the token in DELETE requests.
>>
>>     HTTP/1.1 200 OK
>>     Content-Type: application/json
>>     Cache-Control: no-store
>>     {
>>       "access_token":"SlAV32hkKG/hhh/&%",
>>       "access_token_id":"234567890",
>>       "expires_in":3600,
>>       "refresh_token":"8xLOxBtZp8&&&#&",
>>       "refresh_token_id":"asdfghjklhgf"
>>     }
>>
>>
>>  DELETE /tokens?refresh_token_id=asdfghjklhgf HTTP/1.1
>>  Authorization: BASIC czZCaGRSa3F0Mzo4ZVNFSXBucW1N
>>
>> Note: Since tokens become addressable resources on the authz server, 
>> one could also query or modify token data using a GET/PUT requests
>>
>>  GET /tokens?refresh_token_id=asdfghjklhgf HTTP/1.1
>>  Authorization: BASIC czZCaGRSa3F0Mzo4ZVNFSXBucW1N
>>
>>     HTTP/1.1 200 OK
>>     Content-Type: application/json
>>     Cache-Control: no-store
>>
>>     {
>>       "scope":"abc",
>>       "issued_on":"08/11/2010",
>>       "last_usage":"08/13/2010"                   }
>>
>>
>> 2) HTTP Post on dedicated revocation endpoint
>>
>> An additional endpoint is used to revoke tokens. The token to be 
>> revoked is sent as request body parameter.
>>
>>     POST /revocation HTTP/1.1
>>     Host: server.example.com
>>     Content-Type: application/x-www-form-urlencoded
>>     Authorization: BASIC czZCaGRSa3F0Mzo4ZVNFSXBucW1N
>>
>>     refresh_token=n4E9O119d
>>
>> This option requires some support for the client to discover the 
>> revocation endpoint.
>>
>> Please indicate your prefered option (1a, 1b, 1c, and 2) or suggest 
>> additional design options.
>>
>> regards,
>> Torsten.
>> _______________________________________________
>> OAuth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth