+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
> [email protected]
> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
