Hi Vladimir, What would be a value in the aud claim for refresh tokens?
Regards, Andrii On Tue, Feb 9, 2021 at 3:06 AM Vladimir Dzhuvinov <vladi...@connect2id.com> wrote: > Hi Warren, > On 08/02/2021 17:59, Warren Parad wrote: > > None of that justified explicitly stating that refresh token introspection > shouldn't be done. At best it suggests that we should explicitly add > language in the draft to directly encourage it. > > Did you mean discourage? > > But if an AS wants to support it, we shouldn't stop them, or suggest that > they can't do it. > > The current draft doesn't mention refresh tokens at all. Its subject is > the introspection of access tokens by authenticated resource servers and > returning the response as a signed JWT. The use of refresh tokens at the > introspection endpoint, per RFC 7662, is not forbidden by the draft. > > > > Allowing refresh tokens to be introspected can also create a conflict with >> the sec recommendation to rotate them > > > Not following, can you explain this further? > > I just double checked the rotation spec. Use that triggers rotation is > clearly specified as "access token response", so there should actually be > no issues with confusing introspection as use. > > > https://tools.ietf.org/html/draft-ietf-oauth-security-topics-16#section-4.13.2 > > RFC 7662 also seems to imply that a public client with a refresh token > should not normally be able to introspect it, because it can't authenticate > to the AS. > > https://tools.ietf.org/html/rfc7662#section-2.2 > > To prevent token scanning attacks, the endpoint MUST also require > some form of authorization to access this endpoint, such as client > authentication as described in OAuth 2.0 [RFC6749 > <https://tools.ietf.org/html/rfc6749>] or a separate > OAuth 2.0 access token such as the bearer token described in OAuth > 2.0 Bearer Token Usage [RFC6750 <https://tools.ietf.org/html/rfc6750>]. > The methods of managing and > validating these authentication credentials are out of scope of this > specification. > > > Vladimir > > > > Warren Parad > > Founder, CTO > Secure your user data and complete your authorization architecture. > Implement Authress <https://authress.io>. > > > On Mon, Feb 8, 2021 at 4:13 PM Vladimir Dzhuvinov <vladi...@connect2id.com> > wrote: > >> At first it may appear that allowing refresh tokens at the introspection >> endpoint may be a logical thing to do, but in practice there are issues >> with that and from an OAuth 2.x perspective it's not easy to justify. >> >> If the point is to let clients check what authorization they have been >> given OAuth 2.0 already provides a std way to do that - in the access token >> response - the "scope" parameter: >> >> https://tools.ietf.org/html/rfc6749#section-5.1 >> >> RAR has a similar parameter: >> >> https://tools.ietf.org/html/draft-ietf-oauth-rar-03#section-3.4.1 >> >> If the point is to find if a refresh token is still valid - this can be >> found out by simply using it. Allowing refresh tokens to be introspected >> can also create a conflict with the sec recommendation to rotate them. So >> thus it may be a better idea to not let clients assume too much about them. >> >> >> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-16#section-2.2.2 >> >> If the AS is going to expose refresh token data to a client it will also >> have to make a careful judgement what data it exposes. >> >> https://tools.ietf.org/html/rfc7662#section-2.2 >> >> For instance "sub". OAuth 2.x in the relation between AS and client >> actually has no concept or definition of subject / end-user identifier. And >> this is done for a good reason, because it's not a user authentication >> protocol. OIDC was designed for that. And to prevent tracking of users and >> other privacy issues OIDC also specifies pairwise subject IDs. The plain >> OAuth 2.x world doesn't have this. >> >> Vladimir >> On 08/02/2021 11:07, Warren Parad wrote: >> >> It doesn't work that way. You suggested to add language to the draft, >> that means the burden of proof is on you to justify adding it. >> >> Otherwise I could just say why not? >> >> And I can go stronger, what's the purpose of nho introspection endpoint >> at all, and why encourage sending access tokens to the AS? >> >> Even if you can justify access tokens, there currently isn't evidence >> provided why we should explicity discourage. >> >> >> On Mon, Feb 8, 2021, 03:18 Torsten Lodderstedt <tors...@lodderstedt.net> >> wrote: >> >>> >>> >>> Am 08.02.2021 um 00:56 schrieb Warren Parad <wpa...@rhosys.ch>: >>> >>> >>> >>>> I‘m therefore leaning towards explicitly stating in our draft that it >>>> is not intended to be used with refresh tokens. >>> >>> I'm not following, why explicitly state that it isn't intended. If an AS >>> wants to provide a similar JSON response to a query with the refresh token, >>> why not encourage that? >>> >>> >>> Why should we encourage it? >>> >>> >>> Warren Parad >>> >>> Founder, CTO >>> Secure your user data and complete your authorization architecture. >>> Implement Authress >>> <https://www.google.com/url?q=https://authress.io&source=gmail-imap&ust=1613346997000000&usg=AOvVaw267Z448csTGn3F6REIQ9pT> >>> . >>> >>> >>> On Sun, Feb 7, 2021 at 10:58 PM Torsten Lodderstedt <torsten= >>> 40lodderstedt....@dmarc.ietf.org> wrote: >>> >>>> Hi Andrii, >>>> >>>> Am 07.02.2021 um 21:30 schrieb Andrii Deinega <andrii.dein...@gmail.com >>>> >: >>>> >>>> >>>> Hi Torsten, >>>> >>>> thank you for your response. >>>> >>>> My use case is pretty straight forward >>>> >>>> An OAuth client queries the AS to determine the active state of an >>>> access token and gets the introspection response which indicates that this >>>> access token is active (using RFC7662). >>>> >>>> An OAuth client queries the AS to determine the active state of a >>>> refresh token and gets the introspection response which indicates that this >>>> refresh token is active (using RFC7662). >>>> >>>> An OAuth client queries the AS to determine the active state of an >>>> access token and gets the introspection response (JWT) which indicates >>>> that this access token is active (using this draft). >>>> >>>> Now, an OAuth client queries the AS to determine the active state of a >>>> refresh token (using this draft)... How will the introspection response >>>> look like assuming that the client provides the valid refresh token and >>>> technically, nothing stops it from doing so. >>>> >>>> >>>> why should the state be provided as JWT?I think the plain JSON response >>>> is sufficient in that case. I also think using token introspection for >>>> checking the state of a token from the client side has limited utility. The >>>> definitive decision is always made when the client tries to access a >>>> resource. >>>> >>>> I‘m therefore leaning towards explicitly stating in our draft that it >>>> is not intended to be used with refresh tokens. >>>> >>>> best regards, >>>> Torsten. >>>> >>>> >>>> Regards, >>>> Andrii >>>> >>>> >>>> On Sun, Feb 7, 2021 at 4:14 AM Torsten Lodderstedt < >>>> tors...@lodderstedt.net> wrote: >>>> >>>>> Hi Andrii, >>>>> >>>>> thanks for your post. >>>>> >>>>> The draft is intended to provide AS and RS with a solution to exchange >>>>> signed (and optionally encrypted) token introspection responses in order >>>>> to >>>>> provide stronger assurance among those parties. This is important in use >>>>> cases where the RS acts upon the introspection response data and wants the >>>>> AS to take liability re the data quality. >>>>> >>>>> I’m not sure whether there are similar use cases if a client >>>>> introspects a refresh token. What is your use case? >>>>> >>>>> best regards, >>>>> Torsten. >>>>> >>>>> > Am 07.02.2021 um 08:41 schrieb Andrii Deinega < >>>>> andrii.dein...@gmail.com>: >>>>> > >>>>> > Hi WG, >>>>> > >>>>> > draft-ietf-oauth-jwt-introspection-response-10 states that "OAuth >>>>> 2.0 Token Introspection [RFC7662] specifies a method for a protected >>>>> resource to query an OAuth 2.0 authorization server to determine the state >>>>> of an access token and obtain data associated with the access token." >>>>> which >>>>> is true. Although, according to RFC7662, the introspection endpoint allows >>>>> to introspect a refresh token as well. Hence, the question I have is how >>>>> will a token introspection response look like when the caller provides a >>>>> refresh token and sets the "Accept" HTTP header to >>>>> "application/token-introspection+jwt"? >>>>> > >>>>> > I expect there will be no differences, right? >>>>> > >>>>> > If so, I suggest to >>>>> > • replace "a resource server" by "the caller" in section 4 >>>>> (Requesting a JWT Response) >>>>> > • change "If the access token is invalid, expired, revoked" by >>>>> "If a given token is invalid, expired, revoked" in section 5 (JWT >>>>> Response) >>>>> > If not, my suggestion would be to clarify what the AS should do when >>>>> it asked to introspect the refresh token in general and additionally, what >>>>> should happen in the same case based on the type of the caller from the >>>>> AS's point of view. >>>>> > >>>>> > Regards, >>>>> > Andrii >>>>> > >>>>> >>>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> <https://www.google.com/url?q=https://www.ietf.org/mailman/listinfo/oauth&source=gmail-imap&ust=1613346997000000&usg=AOvVaw3ZHWt08dlcHAgxyfj2hrsX> >>>> >>> >> _______________________________________________ >> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth >> >> -- >> Vladimir Dzhuvinov >> >> -- > Vladimir Dzhuvinov > > _______________________________________________ > 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
