Hi Torsten,
++2. No care about token formats or URL length problem.
-1: all options bring some problems along (as you already indicated).
Additionally, an overloading of HTTP DELETE (as Igor mentioned) is not
an option from my point of view. Every overloading would be deployment
specific (or has to be defined by the OAuth spec???) and I doubt that it
is possible to overload this method with widely-used frameworks.
-1c: Introduction of token ids: If a token is addressed by its ID, it is
IMO not possible to verify in all cases that the client (who requests
revocation/modification) is same client that the token was issued for
before if the authorization server is stateless. So someone might catch
a token and then revokes it.
May there be other security issues?
Another drawback is that the access token response has to be extended.
What kind of modifications of tokens do you have in mind? (as you
commented with 1c)
Regards,
Stefanie
Am 16.08.2010 23:09, schrieb Torsten Lodderstedt:
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
