Subject: [OAUTH-WG] survey: token revocation design options

From: Torsten Lodderstedt <[email-masked]>
Date: Mon, 16 Aug 2010 23:09:29 +0200

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.

---

From: Igor Faynberg <[email-masked]>
Date: Mon, 16 Aug 2010 18:22:50 -0400

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:
> 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:
>
> 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.
>
> c) Authorization servers supporting revocation may additionally issue 
> a URL-safe token id in the access token response. This id is used to 
> Note: Since tokens become addressable resources on the authz server, 
> one could also query or modify token data using a GET/PUT requests
>
>       "last_usage":"08/13/2010"                   }
>
>
> An additional endpoint is used to revoke tokens. The token to be 
> revoked is sent as request body parameter.
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Lukas Rosenstock <[email-masked]>
Date: Tue, 17 Aug 2010 00:51:53 +0200

+1 for your option 1a or 1b

- 1c introduces another "token" to manage with the id, which I feel should
be avoided.
- 2 would also be fine, though not so "beautiful" in terms of architecture.

2010/8/16 Torsten Lodderstedt <[email-masked]>

> 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.

Passing URLs in the query string is already defined in section 5.1.2 of
OAuth, though it is optional for servers to support this method.
The class of services who want to support 5.1.2 and those who want to
support revocation might not match, though ...

-- 
http://lukasrosenstock.net/

---

From: Justin Richer <[email-masked]>
Date: Tue, 17 Aug 2010 09:53:46 -0400

+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

---

From: Torsten Lodderstedt <[email-masked]>
Date: Tue, 17 Aug 2010 20:58:28 +0200

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:
>> 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.
>>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Tue, 17 Aug 2010 21:04:28 +0200

Lukas,

thanks for your feedback.

I think 1c not neccessarily introduces something new to manage. I would 
rather expect implementations use either a ID already contained in the 
token (like the SAML assertion ID) or a base64-encoded version of the 
token itself.

regards,
Torsten.

Am 17.08.2010 00:51, schrieb Lukas Rosenstock:
> - 1c introduces another "token" to manage with the id, which I feel 
> should be avoided.
> 2010/8/16 Torsten Lodderstedt <[email-masked] 
> <mailto:[email-masked]>>
>
> Passing URLs in the query string is already defined in section 5.1.2 
> of OAuth, though it is optional for servers to support this method.

---

From: Igor Faynberg <[email-masked]>
Date: Tue, 17 Aug 2010 16:29:36 -0400

Yes, as I thought we HAD to cope with it. Anyway, both 1a and 1c look 
attractive to me.  (BTW, I saw a comment on overloading of DELETE, with 
which I sympathize in principle, but it looks to me that all methods 
have been already overloaded, while DELETE semantically resonates with 
the very nature of the task at hand.)

Igor

Torsten Lodderstedt wrote:
>  ... [1c] could be combined with 1a or 1b but why? To cope with URL 
> length restrictions?
>
> ...
>
>> 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.)
>>
>>> 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.
>>>
>>> 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

---

From: Stefanie Dronia <[email-masked]>
Date: Wed, 18 Aug 2010 15:04:43 +0200

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

---

From: Marius Scurtescu <[email-masked]>
Date: Tue, 24 Aug 2010 14:39:27 -0700

+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?

Thanks,
Marius

On Wed, Aug 18, 2010 at 6:04 AM, Stefanie Dronia <[email-masked]> wrote:
> 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.
> What kind of modifications of tokens do you have in mind? (as you commented
> with 1c)
>
> Regards,
> Stefanie
>
>
>> 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.
>>
>> 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:
>>
>> Note: As an additional challenge, self-contained tokens can be very large.
>> So passing them as URI parameter may exceed URL length limits.
>>
>> 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

---

From: Torsten Lodderstedt <[email-masked]>
Date: Wed, 25 Aug 2010 00:42:44 +0200

> 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<[email-masked]>  wrote:
>> Hi Torsten,
>>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sat, 28 Aug 2010 20:58:37 +0200

seams option 2 took the lead by one vote.

1a II
1b I
1c
2 III

If no one objects by 08/29, I start writing the I-D based on option 2.

regards,
Torsten.