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