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