Works for me. The text below needs to be fixed up to match too. On Thu, Jan 29, 2015 at 3:14 PM, John Bradley <ve7...@ve7jtb.com> wrote:
> How about > > +--------+ +---------------+ > | |--(A)-- Authorization Request --->| | > | | + t(code_verifier), t | Authorization | > | | | Endpoint | > | |<-(B)- Authorization Code Grant --| | > | | +---------------+ > | Client | > | | +---------------+ > | |--(C)--- Access Token Request --->| | > | | + code_verifier | Token | > | | | Endpoint | > | |<-(D)------ Access Token ---------| | > +--------+ +--------------- > > > > On Jan 29, 2015, at 7:01 PM, Brian Campbell <bcampb...@pingidentity.com> > wrote: > > 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
