RFC 7662 is not explicit on the refresh token "aud". Omitting the "aud" value or setting it to the AS, the ultimate consumer, appears valid here.
Vladimir On 11/02/2021 23:47, Andrii Deinega wrote: > 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 <mailto: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 <mailto: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 <mailto:tors...@lodderstedt.net>> >>> wrote: >>> >>> >>> >>>> Am 08.02.2021 um 00:56 schrieb Warren Parad >>>> <wpa...@rhosys.ch <mailto: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 >>>> <mailto:40lodderstedt....@dmarc.ietf.org>> wrote: >>>> >>>> Hi Andrii, >>>> >>>>> Am 07.02.2021 um 21:30 schrieb Andrii Deinega >>>>> <andrii.dein...@gmail.com >>>>> <mailto: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 >>>>> <mailto: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 >>>>> <mailto: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 <mailto: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 list >>> OAuth@ietf.org <mailto:OAuth@ietf.org> >>> https://www.ietf.org/mailman/listinfo/oauth >> >> -- >> Vladimir Dzhuvinov >> > -- > Vladimir Dzhuvinov > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org <mailto:OAuth@ietf.org> > https://www.ietf.org/mailman/listinfo/oauth > -- Vladimir Dzhuvinov
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
