Subject: [OAUTH-WG] I-D on token revocation submitted

From: Torsten Lodderstedt <[email-masked]>
Date: Wed, 08 Sep 2010 00:21:40 +0200

I just submited the first version of my I-D for token revocation.

Link: https://datatracker.ietf.org/doc/draft-lodderstedt-oauth-revocation/

The I-D proposes an additional endpoint, which can be used to revoke 
both refresh and access tokens. The objective is to enhance OAuth 
security by giving clients and users explicite control of the 
finalization of the token life cycle, e.g. to implement application 
logout or access authorization removal.

Please take the time to review the document (2 pages, essentially) and 
give me feedback. My goal is that this draft becomes a working group 
document.

regards,
Torsten.

---

From: Stefanie Dronia <[email-masked]>
Date: Thu, 09 Sep 2010 19:52:42 +0200

Hallo Torsten,

first of all thanks for providing this draft on the mailing list.
Except for the following words, the draft is consistent. It defines the 
end of a token's life cycle, intended by the user.

While reading it, I think that the following part of chapter 2 (Token 
Revocation) might cause problems a a certain situation:

"If the processed token is a refresh token and the authorization
    server supports the revocation of access tokens, then the
    authorization server must also invalidate all access tokens issued
    for that refresh token."

Situation:
Authz Server(s) and Resource Server(s) are separate systems that are set 
in an open triangle (no communication between them e.g. to verify access 
tokens).

Problem:
How does the Resource Server(s) know that an access token was revoked 
and is not valid to access resources any more?
=> Communication  between the servers necessary
=> benefit of open triangle architecture are lost for this case.
I think that this is a problem with large scale systems.

Although, if there are several Authz Server(s) , then there has to be 
communication between there or a shared data base to assure that revoked 
(refresh) tokens are invalid.

=> Is this requirement really a MUST?
I don't think so.

Any thoughts?

Regards,
Stefanie

Am 08.09.2010 00:21, schrieb Torsten Lodderstedt:
> Link: 
> https://datatracker.ietf.org/doc/draft-lodderstedt-oauth-revocation/
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: Brian Campbell <[email-masked]>
Date: Thu, 9 Sep 2010 16:38:54 -0600

Isn't that kind of situation exactly the reason that access token
revocation was made optional?   Invalidation of access tokens on
revocation of a refresh token is only a MUST, if the deployment
already supports revocation of access tokens.  And if revocation of
access tokens is supported, I'd assume the deployment already has an
efficient means of invalidating them.

Editorial note: shouldn't the "must" in that text be a "MUST"?

On Thu, Sep 9, 2010 at 11:52 AM, Stefanie Dronia <[email-masked]> wrote:
> Except for the following words, the draft is consistent. It defines the end of a token's life cycle, intended by the user.
>
> While reading it, I think that the following part of chapter 2 (Token Revocation) might cause problems a a certain situation:
>
> Authz Server(s) and Resource Server(s) are separate systems that are set in an open triangle (no communication between them e.g. to verify access tokens).
>
> Problem:
> How does the Resource Server(s) know that an access token was revoked and is not valid to access resources any more?
> Although, if there are several Authz Server(s) , then there has to be communication between there or a shared data base to assure that revoked (refresh) tokens are invalid.
>
>> The I-D proposes an additional endpoint, which can be used to revoke both refresh and access tokens. The objective is to enhance OAuth security by giving clients and users explicite control of the finalization of the token life cycle, e.g. to implement application logout or access authorization removal.
>>
>> Please take the time to review the document (2 pages, essentially) and give me feedback. My goal is that this draft becomes a working group document.
>>
>> regards,
>> Torsten.
>>
>>
>>

---

From: Stefanie Dronia <[email-masked]>
Date: Sat, 11 Sep 2010 18:52:55 +0200

Hi Brain,

yes, you are right. I just went over that condition.

On the other hand, this implies to me, that access token revocation is 
not possible in a constellation as described before.

Regards,
Stefanie

Am 10.09.2010 00:38, schrieb Brian Campbell:
> On Thu, Sep 9, 2010 at 11:52 AM, Stefanie Dronia<[email-masked]>  wrote:
>>   Hallo Torsten,
>>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sun, 12 Sep 2010 12:13:24 +0200

Stefanie,

thanks for your comments.

I think there is a subtle difference between revoking access tokens 
directly and indirectly via refresh tokens. In the later case, the 
authorization server needs to keep track of the relation between refresh 
and access tokens (somewhere in a database), whereas the relation 
between access and refresh token could be kept in the access token only.

regards,
Torsten.

Am 11.09.2010 18:52, schrieb Stefanie Dronia:
>>> Except for the following words, the draft is consistent. It defines 
>>> the end of a token's life cycle, intended by the user.
>>>
>>> While reading it, I think that the following part of chapter 2 
>>> (Token Revocation) might cause problems a a certain situation:
>>>
>>> Authz Server(s) and Resource Server(s) are separate systems that are 
>>> set in an open triangle (no communication between them e.g. to 
>>> verify access tokens).
>>>
>>> Problem:
>>> How does the Resource Server(s) know that an access token was 
>>> revoked and is not valid to access resources any more?
>>> Although, if there are several Authz Server(s) , then there has to 
>>> be communication between there or a shared data base to assure that 
>>> revoked (refresh) tokens are invalid.
>>>
>>>> The I-D proposes an additional endpoint, which can be used to 
>>>> revoke both refresh and access tokens. The objective is to enhance 
>>>> OAuth security by giving clients and users explicite control of the 
>>>> Please take the time to review the document (2 pages, essentially) 
>>>> and give me feedback. My goal is that this draft becomes a working 
>>>> group document.
>>>>
>>>> regards,
>>>> Torsten.
>>>>
>>>>
>>>>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sun, 12 Sep 2010 12:15:16 +0200

> Editorial note: shouldn't the "must" in that text be a "MUST"?

You are right. I changed that.

regards,
Torsten.

---

From: Brian Campbell <[email-masked]>
Date: Tue, 14 Sep 2010 16:32:15 -0600

So is my understanding of the draft incorrect?  I read it to say that
direct access token revocation is optional but, if supported, then all
associated assess tokens must also be revoked on a revocation of a
refresh token.

On Sun, Sep 12, 2010 at 4:13 AM, Torsten Lodderstedt
<[email-masked]> wrote:
> I think there is a subtle difference between revoking access tokens directly
> and indirectly via refresh tokens. In the later case, the authorization
> server needs to keep track of the relation between refresh and access tokens
> (somewhere in a database), whereas the relation between access and refresh
> token could be kept in the access token only.
>
> regards,
> Torsten.
>
>> On the other hand, this implies to me, that access token revocation is not
>> possible in a constellation as described before.
>>
>> Regards,
>> Stefanie
>>
>>>>> both refresh and access tokens. The objective is to enhance OAuth security
>>>>> by giving clients and users explicite control of the finalization of the
>>>>> token life cycle, e.g. to implement application logout or access
>>>>> authorization removal.
>>>>>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Wed, 15 Sep 2010 07:37:49 +0200

Your understanding is correct. I just wanted to note the additional data required at the authz server in order to implement the indirect case.

Regards,
Torsten.

Am 15.09.2010 um 00:32 schrieb Brian Campbell <[email-masked]>:

> So is my understanding of the kraft incorrect?  I read it to say that