Re: [OAUTH-WG] Detailed review of OAuth2.1
Thank you very much for your detailed feedback Vittorio! ᐧ On Tue, Dec 8, 2020 at 3:22 PM wrote: > Dear authors, > > It took ages but I finally managed to go thru a full review of the current > OAuth2.1 draft. Apologies for the delay. > > Metacomments: > >- The VAST majority of the comments are suggestions for improving >clarity, mostly on historical language coming from 2.0 that I found myself >having to clarify to customers and colleagues over and over thru the years. >None of those are critical. >- There are a few places where 2.1 requires a MUST I believe to be >unwarranted/too restrictive. For each of those I did my best to provide >context and concrete examples. >- A sizeable category of comments and disagreements on MUST come from >treating mobile and desktop apps as largely equivalent under the “native >app” umbrella, despite of the vast gulf that separates the two both in >terms of security posture and user experience. Again, I tried to be as >matter of fact as possible in there. >- The main reason for which I spoke up during the IETF interim on >oauth2.1 was the confusion the omission f the implicit grant caused among >the devs using implicit in OIDC for obtaining ID_tokens. I suggested some >language to pre-empt the issue, but I expect some iteration there. > > Thanks, > > V > > > > §1 > > I wonder whether we should take the opportunity offered by OAuth2.1 to > clarify frequent points of confusion about OAuth, by explicitly calling out > in the introduction what is out of scope. > > For example: OAuth is not an identity protocol, as it doesn’t concern > itself with how resource owners are authenticated; OAuth isn’t meant to > address 1st party scenarios, although the reader is free to use it in > that context as well; and so on. > > I believe there is value in adding this in the introduction rather than > relegating it in some later considerations section, as the people who need > this information the most rarely read past this point. > > > > §1.1 > > In the RS definition, wondering whether including the word “API” would > help to clarify what an RS is in practice. > > > > §1.2 > > I always found this part extraordinarily difficult to decipher. I get that > this is the first description and doesn’t have to be exhaustive and > consider all cases (eg it’s ok if step 3 claims that the client > authenticates w the AS even tho that’s only for confidential clients), but > I think it could be much clearer than it is today. > > Step 1 says > > The client requests authorization from the resource owner. The > authorization request can be made directly to the resource owner (as > shown), or preferably indirectly via the authorization server as an > intermediary. > > Besides the fact that “requests authorization” is a bit vague, this step > and the corresponding diagram leg does not correspond at all to what > normally happens- to get a code, the client does need to hit the AS and the > mention in passing in the text isn’t enough to figure that out. Also, with > the omission of ROPG there really isn’t any way of asking anything to the > RO directly (the client creds doesn’t involve the RO). > > I would recommend updating that diagram to be more descriptive of the > canonical scenario. > > Step 2 > > mentions the 2 grants defined in the spec, but only one of them represents > the RO’s authorization. Claiming that the client itself is the RO is a > formalism that doesn’t meet the reader’s intuition at this point. > > Step 5 > > The language here triggered multiple discussions, in particular on whether > the AT can actually be used to ascertain the identity of the client – that > isn’t the case for public clients, for example; besides, that’s not really > the highest order bit of the AT. If it is, it seems that the spec should be > more explicit about how client identification from the RS by means of an AT > works. If it isn’t, perhaps we should change the language to omit > authenticate. > > The last paragraph is emblematic IMO – if the preferred method is very > different from the diagram here, and if the abstraction presented here is > not terribly useful (given that we no longer have multiple RO based grants, > excluding the extension grants that are still too far at this point to > warrant a cognitive downpayment for the reader) I wonder whether we’d be > better off doing the authz code diagram directly (and mention that we also > have the client creds grant separately). > > > > §1.3 > > I understand that we can’t really change this because we inherit from > OAuth 2 but I’ll mention it anyway- modeling clients as ROs is problematic, > as it doesn’t often match what happens in practice. A confidential client > might batch-read a user’s inbox searching for ad words, but the resource > owner remains the user. > > I know we straighten things up in 1.3.2, but the positioning here is > confusing. > > Also: isn’t the refresh token grant a core-s
Re: [OAUTH-WG] Detailed review of OAuth2.1
Thanks as lot Vittorio! You gave us a lot of homework but I think the draft will be improved a lot based on it. Re OIDC implicit: I‘m reluctant to explicitly endorse use of OIDC implicit (response type „id_token“ or „code id_token“) as there are examples in the wild where the id_token is used as access token. Moreover, I‘m not aware of any systematic security threat analysis of those flows. I‘m fine with pointing out to readers that omission of response type „token“ does not deprecate other extension response types. WDYT? > Am 09.12.2020 um 01:55 schrieb Dick Hardt : > > > Thank you very much for your detailed feedback Vittorio! > ᐧ > >> On Tue, Dec 8, 2020 at 3:22 PM wrote: >> Dear authors, >> >> It took ages but I finally managed to go thru a full review of the current >> OAuth2.1 draft. Apologies for the delay. >> >> Metacomments: >> >> The VAST majority of the comments are suggestions for improving clarity, >> mostly on historical language coming from 2.0 that I found myself having to >> clarify to customers and colleagues over and over thru the years. None of >> those are critical. >> There are a few places where 2.1 requires a MUST I believe to be >> unwarranted/too restrictive. For each of those I did my best to provide >> context and concrete examples. >> A sizeable category of comments and disagreements on MUST come from treating >> mobile and desktop apps as largely equivalent under the “native app” >> umbrella, despite of the vast gulf that separates the two both in terms of >> security posture and user experience. Again, I tried to be as matter of fact >> as possible in there. >> The main reason for which I spoke up during the IETF interim on oauth2.1 was >> the confusion the omission f the implicit grant caused among the devs using >> implicit in OIDC for obtaining ID_tokens. I suggested some language to >> pre-empt the issue, but I expect some iteration there. >> Thanks, >> >> V >> >> >> >> §1 >> >> I wonder whether we should take the opportunity offered by OAuth2.1 to >> clarify frequent points of confusion about OAuth, by explicitly calling out >> in the introduction what is out of scope. >> >> For example: OAuth is not an identity protocol, as it doesn’t concern itself >> with how resource owners are authenticated; OAuth isn’t meant to address 1st >> party scenarios, although the reader is free to use it in that context as >> well; and so on. >> >> I believe there is value in adding this in the introduction rather than >> relegating it in some later considerations section, as the people who need >> this information the most rarely read past this point. >> >> >> >> §1.1 >> >> In the RS definition, wondering whether including the word “API” would help >> to clarify what an RS is in practice. >> >> >> >> §1.2 >> >> I always found this part extraordinarily difficult to decipher. I get that >> this is the first description and doesn’t have to be exhaustive and consider >> all cases (eg it’s ok if step 3 claims that the client authenticates w the >> AS even tho that’s only for confidential clients), but I think it could be >> much clearer than it is today. >> >> Step 1 says >> >> The client requests authorization from the resource owner. The >> authorization request can be made directly to the resource owner (as shown), >> or preferably indirectly via the authorization server as an intermediary. >> >> Besides the fact that “requests authorization” is a bit vague, this step and >> the corresponding diagram leg does not correspond at all to what normally >> happens- to get a code, the client does need to hit the AS and the mention >> in passing in the text isn’t enough to figure that out. Also, with the >> omission of ROPG there really isn’t any way of asking anything to the RO >> directly (the client creds doesn’t involve the RO). >> >> I would recommend updating that diagram to be more descriptive of the >> canonical scenario. >> >> Step 2 >> >> mentions the 2 grants defined in the spec, but only one of them represents >> the RO’s authorization. Claiming that the client itself is the RO is a >> formalism that doesn’t meet the reader’s intuition at this point. >> >> Step 5 >> >> The language here triggered multiple discussions, in particular on whether >> the AT can actually be used to ascertain the identity of the client – that >> isn’t the case for public clients, for example; besides, that’s not really >> the highest order bit of the AT. If it is, it seems that the spec should be >> more explicit about how client identification from the RS by means of an AT >> works. If it isn’t, perhaps we should change the language to omit >> authenticate. >> >> The last paragraph is emblematic IMO – if the preferred method is very >> different from the diagram here, and if the abstraction presented here is >> not terribly useful (given that we no longer have multiple RO based grants, >> excluding the extension grants th
