+--------+ +---------------+
| |--(A)-- Authorization Request --->| |
| | + t(code_verifier), t | Authorization |
| | | Endpoint |
| |<-(B)---- Authorization Code -----| |
| | +---------------+
| Client | Authz Server
| | +---------------+
| |--(C)--- Access Token Request --->| |
| | + code_verifier | Token |
| | | Endpoint |
| |<-(D)------ Access Token ---------| |
+--------+ +---------------+
Figure 2: Abstract Protocol Flow
Sakimura, et al. Expires August 2, 2015 [Page 4]
Internet-Draft oauth_pkce January 2015
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 Authorization Endpoint responds as usual, but records
"t(code_verifier)" and the transformation method.
C. The client then sends the code in 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.
> On Jan 29, 2015, at 7:16 PM, Brian Campbell <bcampb...@pingidentity.com>
> wrote:
>
> 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
> <mailto: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
>> <mailto: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
