search

oauth-wg / oauth-v2-1

OAuth 2.1 is a consolidation of the core OAuth 2.0 specs
https://oauth.net/2.1/
Other
51 stars 28 forks source link

Update "Protocol Flow" introduction section #26

Open aaronpk opened 3 years ago

aaronpk commented 3 years ago

from Vittorio:

§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).

aaronpk commented 3 years ago

and from Justin:

§1.2: This diagram could use an update to not show the client talking directly to the RO in the first step, especially because the ROPC grant has been removed here. The way it’s written now makes it look like the user gives something to the client which it then trades for a token directly, which doesn’t happen quite like that anywhere.

dickhardt commented 3 years ago

The diagram is an abstract protocol flow of who talks to who. I do agree it is confusing as drawn, and the description is quite confusing.

tlodderstedt commented 3 years ago

I'm understanding the attempt to come up with an abstract description of the flow, but I don't see a common denominator between client credential, code and refresh token. I suggest to focus on the grant specific flow descriptions or perhaps one for code + refresh token to give a bigger picture.

aaronpk commented 2 years ago

Also related to #29 "Clarify 'authorization grant'"