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
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth