In SPOP/PKCE §1.1 [1] the figure and explanation have the authorization request going to the "Resource Owner" and goes on to say that 'the resource owner responds as usual, but records "t(code_verifier)" and the transformation method.' That's not what the resource owner does.
I know the protocol flow in RFC 6749 tries to have authorization grants be these abstract things that sorta come from the resource owner but, in the context of the the authorization request and authorization code grant type, it really doesn't work like that. The content in §1.1 seems, at best, to be more abstract and complicated than it needs to be and is bordering on being just kinda wrong. The RO and AS boxes should probably be consolidated into just the AS. The RO could be omitted from the diagram, I think. Or stick it over with the client, if you really want it in there, and have it authenticating and approving authorization though an interaction with the AS. Or something like that... [1] https://tools.ietf.org/html/draft-ietf-oauth-spop-06#section-1.1 1.1 <https://tools.ietf.org/html/draft-ietf-oauth-spop-06#section-1.1>. Protocol Flow +--------+ +---------------+ | |--(A)-- Authorization Request --->| | | | + t(code_verifier), t | Resource | | | | Owner | | |<-(B)--- Authorization Grant -----| | | | +---------------+ | Client | | | +---------------+ | |--(C)--- Access Token Request --->| | | | + code_verifier | Authorization | | | | Server | | |<-(D)------ Access Token ---------| | +--------+ +---------------+ Figure 2: Abstract Protocol Flow This specification adds additional parameters to the OAuth 2.0 Authorization and Access Token Requests, shown in abstract form in Figure 1. A. The client creates and records a secret named the "code_verifier", and derives a transformed version "t(code_verifier)" (referred to as the "code_challenge") which is sent in the OAuth 2.0 Authorization Request, along with the transformation method "t". B. The resource owner responds as usual, but records "t(code_verifier)" and the transformation method. C. The client then sends the code to the Access Token Request as usual, but includes the "code_verifier" secret generated at (A). D. The authorization server transforms "code_verifier" and compares it to "t(code_verifier)" from (B). Access is denied if they are not equal.
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
