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

[Torsten Lodderstedt <[e-mail]>]

  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