در بخش چهارم، موضوعات پیرامون Authentication و OpenID Connect (OIDC) را بررسی کردیم.
در این بخش، (Proof Key for Code Exchange) PKCE یا pixy، که برای public clientهای موبایل طراحی شده است را بررسی می کنیم.
زمانی که در مورد clientهای موبایل صحبت می کنیم، باید به این مساله توجه کنیم که در مورد trusted application صحبت نمی کنیم. گاهی اوقات در flowهای مختلف از OAuth، با trusted appهایی روبرو هستیم که از Resource Owner Password Credential (ROPC) flow استفاده می کنند. به این صورت که یوزر و پسورد را از کاربر دریافت می کنند، به سمت identity server ارسال می کنند و access token را دریافت می کنند.
موضوع صحبت ما در مورد یک mobile app می باشد که نیاز به authorization server دارد. در client device، یک mobile app برای انجام عملیات login، باید browser را باز کند، از طریق آن redirection را انجام دهد و call back را دریافت کند. برای نمونه می توانیم online payment را مثال بزنیم.
اولین موضوعی که وجود دارد، جریان custom URI scheme می باشد. این جریان به این موضوع می پردازد که ما می توانیم یک scheme تعریف کنیم و در سیستم عامل register کنیم.
String url = ”selphone://post_detail?post_id=10" Intent intent = new Intent(Intent.ACTION_VIEW, Uri.parse(url)); startActivity(intent);
شما می توانید app خود را به عنوان handler این uri در نظر بگیرید.
نکته ای که هست، ممکن است application دیگری در آن سیستم عامل نصب شده باشد که خودش را به عنوان handler آن uri معرفی کرده باشد. در مرحله اول از سمت app، یک authorization request از طریق browser و redirection به صورت امن اتفاق می افتد و login انجام می شود. در مرحله بعد و در بازگشت به همراه authorization code، این مساله ممکن است اتفاق بیافتد. app آلوده می تواند در این مرحله code را دریافت کند و از access token استفاده کند.
این حمله، در native appها شناسایی می شود و منجر به معرفی pixy و ایده هایی می شود که می تواند علاوه بر mobile app، برای single page application (spa)ها هم مناسب باشد.
راه حلی که ارائه شد، application در لحظه انجام authorization request redirection، یه کد که اصلاحا code verifier می گویند، تولید می کند و برای authorization در کنار requestهای خود ارسال می کند. زمانی که authorization code برمی گردد، اگر PKCE فعال باشد، کسی که exchange را بخواهد انجام دهد باید code verifier را داشته باشد. authorization code به همراه code verifier ارسال می شود و access token دریافت می شود. بنابراین قابلیت exchange از نرم افزار آلوده گرفته می شود.
در نتیجه چون public clientها client secret ندارند، PKCE یک random secret برای آن ایجاد می کند و نزد خود نگه می دارد. اپلیکیشن های موبایل هم جزو اپلیکیشن های public تلقی می شوند.
اصلاحاتی که در این زمینه نیاز داریم با آن ها آشنا باشیم، شامل موارد زیر است.
code verifier
یک random code است که به در زمان authorization request توسط client تولید می شود. حداقل 43 کارکتر و حداکثر 128 کارکتر می تواند باشد.
code challenge
برای تعریف code challenge دو متد plain و S256 وجود دارد. در plain که استفاده از آن توصیه نمی شود، هیچ عملیاتی بر روی code verifier اتفاق نمی افتد و code verifier به همان شکل در قالب یک code challenge به سرور ارسال می شود. در S256، عبارت code verifier از طریق الگوریتم SHA256 تبدیل به hash و از طریق Base64 تبدیل به encode و در نهایت code challenge می شود.
code challenge method
روش اعمال تغییراتی است که بر روی code verifier اعمال می شود.
در زمان ارسال authorization request به سمت سرور، غیر از پارامترهایی مانند response_type و scope که قبلا ارسال می کردیم، دو پارامتر code_challenge و code_challenge_method که با مقادیر plain یا S256 پر می شود، ارسال می شوند.
در مرحله ای که client قصد دارد عملیات exchange را انجام دهد، نیاز به ارسال پارمتر code_verifier داریم.
سرور بر اساس code_challenge و code_verifier ارسال شده، می تواند verification را انجام دهد.
استفاده از authorization code flow در browser web applicationها، به همراه PKCE به عنوان یک روش برای جلوگیری از intercept کردن مطرح می شود. در این صنعت با سه architecture کلی روبرو هستیم.
همانطور که در مطالب گذشته اشاره شد، OAuth از لحاظ تاریخچه ای برای delegate کردن دسترسی یک کاربر به یک third-party تعریف شده است. اما رفته رفته متوجه شدیم که OAuth نه تنها برای third-partyها کاربردی است، بلکه برای first-party applicationها هم می تواند مناسب باشد. first-party application به appهایی گفته می شود که client و API توسط یک شخص یا سازمان نوشته شده باشد.
در OAuth 2.1 و در Best Current Practice (BCP)، استفاده از Implicit flow و Resource Owner
(ROPC) Password Credential flow به طور کامل رد شده است و تنها با Code flow و Client Credentials flow روبرو هستیم.
دلیل این کار را می توانیم در سه موضوع دنبال کنیم.
استفاده از ROPC، این محدودیت را به همراه دارد که حتما باید از روش username و password استفاده می کردیم. استفاده از redirection base flows، می تواند به identity provider قابلیت این را بدهد که فارغ از موضوع username و password، از روش های دیگر مثل Multi-factor authentication ،Biometric authentication و روش های که در آینده به آن ها اشاره می کنیم، استفاده کند.
موضوع بعدی قابلیت Single sign-on می باشد که صرفا از طریق flowهایی قابل دسترسی است که redirection base می باشند.
و موضوع آخر که در flowهای redirection base داریم، استفاده از identity providerهای بیرونی است. یعنی در صفحه identity provider، به جای استفاده از username و password، برای مثال از google login استفاده می کنم.
در browser-based applicationها، با سه architecture کلی روبرو هستیم.
در architecture اول، JavaScript applicationها می توانند با resource server، در یک دامین باشند، کوکی های مشترک داشته باشند و بین هم به اشتراک بگذارند. در حال حاضر، تیم ها کمتر به سراغ توسعه همچین اپلیکیشن هایی می روند.
در architecture دوم، resource server جدا است و client به دو بخش JavaScript front و back end تقسیم می شود. این مورد هم کمتر استفاده می شود.
در architecture سوم که رایج ترین حالت امروز applicationها است، JavaScript applicationهایی هستند که back end ندارند و مستقیما به resource server وصل می شوند. اصلاحا آن ها را به نام Single Page Application یا SPA می شناسیم.
موضوع صحبت ما بیشتر در مورد architecture سوم است. این architecture را به عنوان یک public client می شناسیم بنابراین راهی امن برای نگهداری client secret در آن وجود ندارد. در اینجا، request authorization code به همراه PKCE خواهد بود. در access token request، از طریق یک post request، عملیات ارسال authorization code و PKCE به سمت authorization server را انجام می دهد و access token را دریافت می کند. در browser-based applicationها، مساله CORS باید در authorization serverها دیده شود.
استفاده از PKCE یک الزام در browser-based applicationها می باشد.
دو پارامتر به نام های response_type و response_mode وجود دارد که در OIDC اضافه شده اند.
پارامتر response_type تعریف می کند که ما از چه نوع flow داریم استفاده می کنیم و با آن آشنایی داریم.
در درخواستی که OIDC Client به سمت سرور ارسال می کند، پارامتری به نام response_mode وجود دارد.
پارامتر response_mode، مکانیزم برگشت از authorization endpoint را مشخص می کند. در response_mode دو مقدار query و fragment وجود دارد. اگر مقدار برابر query باشد، authorization server عملیات redirect callback را با query string انجام می دهد. و اگر مقدار برابر fragment باشد، در قالب fragment صفحه برمی گردد.
در OIDC، اگر از code flow استفاده کنیم، مقدار response_mode به صورت پیش فرض بر روی query خواهد بود و اگر از implicit flow استفاده کنیم برابر fragment خواهد بود.
