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 <bcampb...@pingidentity.com>: > 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 > <tors...@lodderstedt.net> 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<sdro...@gmx.de> 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 >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>> >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >> >> _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
