Am 24.08.2010 23:39, schrieb Marius Scurtescu:
+2
1c introduces one more token that needs to be managed, both by the
client and by the server.
1a/b/c has one more issue, tokens are more exposed than usual and if
revocation fails this can be problematic.
Both access and refresh tokens should be revocable, right?
Yes.
regards,
Torsten.
Thanks,
Marius
On Wed, Aug 18, 2010 at 6:04 AM, Stefanie Dronia<sdro...@gmx.de> wrote:
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
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
