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

[Torsten Lodderstedt <[e-mail]>]

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 <[e-mail]>:

> So is my understanding of the kraft 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
> <[e-mail]> wrote:
>>  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:
>>> 
>>>  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:
>>>> 
>>>> 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<[e-mail]>  wrote:
>>>>> 
>>>>>  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:
>>>>>> 
>>>>>>  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.
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> _______________________________________________
>>>>>> OAuth mailing list
>>>>>> [e-mail]
>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>> 
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>> 
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>> 
>>> _______________________________________________
>>> OAuth mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/oauth
>> 
>>