جریان پروتکل Oauth PKCE به شرح زیر است ، همانطور که در RFC 7636 تعریف شده است:

                                              + ------------------- +
                                             | سرور Authz |
   + -------- + | + --------------- + |
   | | - (الف) - درخواست مجوز ----> | | |
   | | + t (code_verifier) ​​، t_m | | مجوز | |
   | | | | نقطه پایانی | |
   | | <-(B)---- Authorization Code -----|               | |
   |        |                                | +---------------+ |
   | Client |                                |                   |
   |        |                                | +---------------+ |
   |        |--(C)-- Access Token Request ----> | | |
   | | + code_verifier | | گفتن | |
   | | | | نقطه پایانی | |
   | | <- (D) ------ نشانه دسترسی --------- | | |
   + -------- + | + --------------- + |
                                             + ------------------- +

سؤال من این است: چرا ما نیاز داریم از پله ای مانند S256 در مرحله (A) استفاده کنیم؟ ارتباط در (A) یا (C). بنابراین چرا یک برنامه نمی تواند یک مقدار تصادفی را در (A) ایجاد کند و مجدداً از آن در (C) استفاده کند؟

برای توضیح: هدف t (code_verifier) ​​ (یعنی S256 (code_verifier) ​​) بعداً این برنامه را قادر می سازد تا به سرور ثابت كند كه واقعاً این برنامه همانگونه است كه دارای code_verifier قبل از تبدیل است.

اگرچه برنامه فقط ارسال code_verifier و بعداً دوباره آنرا ارسال كرد ، با همان ضمانت حاصل مي شود: سرور مقدار تصادفي را دريافت مي كند كه برنامه را بطور جداگانه مشخص مي كند و دوباره آن را دريافت مي كند. هیچ برنامه دیگری نمی تواند این ارزش را ارائه دهد: تا زمانی که اتصال متوقف نشده باشد (و نباید باشد – TLS) ، S256 به نظر غیر ضروری است.