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

[Justin Richer <[e-mail]>]

+2   ;)

I don't like the use of the DELETE method, it feels too much like
overloading the semantics of the HTTP definitions. And as you outline
below, there are a few obstacles on it to make it really workable
anyway.

Another option not laid out below is a parameter on the token endpoint
to suggest revocation and/or modification. However, with the new
language around grant_types and the like, this makes less sense than it
used to.

 -- Justin

On Mon, 2010-08-16 at 17:09 -0400, 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