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

[Brian Campbell <[e-mail]>]

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