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 > <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. >
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
