تفاوت بین OAUTH 2 و OAUTH 2. 1

OAUTH 2. 1 در حال تحکیم بهترین شیوه های آموخته شده در طی هشت سال از زمان انتشار OAUTH 2 است. مشخصات اصلی OAUTH 2. 0 در اکتبر 2012 با عنوان RFC 6749 و RFC 6750 منتشر شد. این جایگزین OAUTH 1. 0 شد ، که در آوریل 2010 منتشر شد. در طی سالهای بعد تعدادی از پسوندها و اصلاحات در OAUTH 2 وجود داشته است.

مشخصات جدید OAUTH ارائه شده است و هم اکنون در حال بحث است. در این زمان ، مشخصات اخیراً در تاریخ 30 ژوئیه 2020 به روز شده است. در صورت تصویب ، OAUTH 2. 1 بخش های خاصی از OAuth 2. 0 را منسوخ می کند و بهترین روش های امنیتی را به عهده می گیرد. بقیه مشخصات OAUTH 2. 0 حفظ خواهد شد.

که تکرار می شود. هیچ چیز جدیدی اضافه نمی شود. این یک هدف طراحی صریح OAUTH 2. 1 است.

این مقاله فرض می کند که شما یک توسعه دهنده هستید یا تجربه فنی مشابهی دارید و با OAUTH و اصطلاحات مورد استفاده در استانداردهای مختلف مربوطه آشنا هستید. اگر دوست دارید مقدمه ای برای OAUTH داشته باشید و چرا از آن استفاده می کنید ، ویکی پدیا مکان خوبی برای شروع است. این مقاله تغییرات پیشنهادی را در OAUTH شامل می شود که ممکن است در صورت استفاده از OAUTH در برنامه خود یا اینکه نرم افزاری را ایجاد می کنید که OAUTH را پیاده سازی می کند ، بر شما تأثیر بگذارد.

چرا OAUTH 2. 1؟

مدت زمان زیادی از انتشار OAUTH 2. 0 گذشته است ، بنابراین انتشار نقطه ادغام به ساده تر کردن اجرای کمک می کند. همانطور که در یک پست وبلاگ توسط هارون پارکی ، یکی از نویسندگان مشخصات پیش نویس OAUTH 2. 1 بیان شده است:

هدف اصلی من با OAUTH 2. 1 گرفتن بهترین شیوه های فعلی در OAUTH 2. 0 و همچنین پسوندهای خوب آن با یک نام واحد است. این همچنین به معنای خاص است که این تلاش هیچ رفتار جدیدی را تعریف نمی کند ، بلکه فقط گرفتن رفتار تعریف شده در سایر مشخصات است. همچنین شامل چیزی نیست که آزمایشی یا هنوز در دست انجام باشد.

Oauth 2. 1 یک خراش و بازسازی OAuth 2. 0 نیست. در عوض ، OAUTH 2. 1 تغییرات و ترفندهایی را که در هشت سال گذشته به OAUTH 2. 0 ساخته شده است ، ضبط و تلفیق می کند. تمرکز خاصی بر امنیت پیش فرض بهتر وجود دارد. این بهترین شیوه ها را ایجاد می کند و به عنوان یک سند مرجع در حال پیشروی خواهد بود.

در اینجا توضیحات پیشنهادی از بحث لیست پستی در حال حاضر آورده شده است:

با طراحی ، [OAUTH 2. 1] هیچ ویژگی جدیدی را به آنچه در حال حاضر در مشخصات OAUTH 2. 0 جایگزین شده است ، معرفی نمی کند.

بسیاری از جزئیات از سند امنیت OAUTH 2. 0 بهترین شیوه های فعلی تهیه شده است. به نام امنیت بهترین روشها ، برخی از کمک های مالی مشکل ساز تر حذف می شوند.

در پایان روز ، هدف OAUTH 2. 1 داشتن یک سند واحد است که نحوه اجرای بهترین و استفاده از OAUTH را به عنوان یک مشتری و یک سرور مجوز توضیح می دهد. دیگر توسعه دهندگان ملزم به شکار چندین اسناد RFC و استاندارد نیستند تا درک کنند که چگونه یک رفتار خاص باید اجرا یا استفاده شود.

OAUTH 2. 1 چگونه بر شما تأثیر می گذارد؟

اگر در برنامه خود از OAuth استفاده می کنید ، وحشت نکنید.

همانطور که در بالا ذکر شد ، روند بحث پیرامون این مشخصات در حال انجام است. پیش نویس در اواسط ماه ژوئیه به لیست پستی IETF ارسال شد و در ژوئیه سال 2020 توسط کارگروه OAuth به تصویب رسید. از زمان نوشتن ، پیش نویس در حال بررسی و تنظیم دقیق است.

ممکن است بپرسید ، چه زمانی در دسترس خواهد بود؟پاسخ کوتاه "هیچ کس نمی داند".

پاسخ طولانی این است: "واقعاً ، هیچ کس نمی داند. به نظر می رسد که ما در حال پیشرفت هستیم. "

حتی پس از انتشار OAUTH 2. 1 ، احتمالاً مدتی قبل از اجرای گسترده خواهد بود. کمک های بلاعوض ممکن است با NAGS یا هشدارها برای همیشه پشتیبانی شود. تغییرات دقیق در مشخصات هنوز مورد بحث قرار گرفته و انتشار RFC در آینده بیشتر است. سرانجام ، هنگامی که OAUTH 2. 1 منتشر شد ، در صورت پاسخگویی به نیازهای شما می توانید از سرور OAuth 2. 0 استفاده کنید.

گفته می شود ، هنگامی که OAUTH 2. 1 بیشترین تأثیر را در هر کسی که از OAUTH برای تأیید اعتبار یا مجوز در برنامه های خود استفاده می کند ، منتشر می کند ، با حذف دو کمک هزینه مشخص OAUTH 2. 0 سازگار خواهد شد: کمک هزینه ضمنی و اعتبار رمز عبور صاحب منبع.

چه چیزی از OAUTH 2. 0 به OAUTH 2. 1 تغییر می کند؟

پیش نویس RFC دارای بخشی است که تغییرات عمده بین OAUTH 2. 0 و OAUTH 2. 1 را بیان می کند. ممکن است تغییراتی وجود داشته باشد که در آن بخش ضبط نشده باشد اما اهداف نویسندگان این است که همه تغییرات رسمی را در آنجا مستند سازند. شش تغییر از این دست وجود دارد:

کمک هزینه کد مجوز با عملکرد PKCE (RFC7636) گسترش می یابد به طوری که روش پیش فرض استفاده از کمک هزینه کد مجوز مطابق این مشخصات نیاز به افزودن پارامترهای PKCE دارد

تغییر مسیر URI باید با استفاده از تطبیق دقیق رشته مطابق با بخش 4. 1. 3 از OAUTH 2. 0 امنیت بهترین روشهای فعلی مقایسه شود

کمک هزینه ضمنی ("پاسخ_تایپ = توکن") طبق بخش 2. 1. 2 از OAUTH 2. 0 امنیت بهترین روشهای فعلی از این مشخصات حذف شده است

کمک هزینه اعتبار رمز عبور صاحب منبع از این مشخصات طبق بخش 2. 4 از OAUTH 2. 0 امنیت بهترین روشهای فعلی حذف شده است

استفاده از توکن تحمل استفاده از نشانه های تحمل در رشته پرس و جو از URIS طبق بخش 4. 3. 2 از امنیت OAUTH 2. 0 بهترین روشهای فعلی

توکن های تازه کردن باید از نظر فرستنده یا یک بار استفاده شوند یا طبق بخش 4. 12. 2 از OAUTH 2. 0 امنیت بهترین روشهای فعلی

Whew ، خیلی زیاد استبیایید هر یک از این موارد را به نوبه خود بررسی کنیم. اما قبل از انجام این کار ، بگذارید چند اصطلاح استفاده شده در بقیه این مقاله را تعریف کنیم.

• مشتری یک قطعه کد است که کاربر با آن در تعامل است. مرورگرها ، برنامه های بومی یا برنامه های تک صفحه ای همه مشتری هستند.
• یک سرور OAUTH مشخصات OAUTH را پیاده سازی می کند. این اطلاعات را در مورد اینکه کدام منابع در دسترس مشتری است ، دریافت می کند یا می تواند به دست آورد. در RFCS این برنامه به یک سرور مجوز گفته می شود. این همچنین به عنوان ارائه دهنده هویت شناخته می شود. بیشتر کاربران آن را "مکانی که وارد سیستم می شوند" می نامند.
• یک سرور برنامه کاربردی تأیید اعتبار ندارد بلکه در عوض نمایندگان درخواست های ورود به سرور OAuth را وارد می کنند. این یک شناسه دارد که به سرور OAuth اجازه می دهد تا آن را شناسایی کند.

OAUTH 2. 1 تغییر: کمک هزینه کد مجوز به PKCE نیاز دارد

کمک هزینه کد مجوز با عملکرد PKCE (RFC7636) گسترش می یابد به طوری که روش پیش فرض استفاده از کمک هزینه کد مجوز مطابق این مشخصات نیاز به افزودن پارامترهای PKCE دارد

وای! بسیار زیاد است. بیایید آن را تجزیه کنیم. کمک هزینه کد مجوز یکی از متداول ترین کمک های مالی OAuth است و امن ترین است. اگر در نمودارهای جریان قرار دارید ، در اینجا یک پست در مورد کمک هزینه کد مجوز با استفاده از یک نمودار و قدم زدن در گام به گام به کمک هزینه ارائه می شود.

کلید اثبات برای Code Exchange (PKCE) RFC در سال 2015 منتشر شد و در صورت وقوع بخشی از جریان مجوز در یک اتصال غیر TLS ، کمک هزینه کد مجوز را برای محافظت از حمله گسترش می دهد. به عنوان مثال ، در صورت وجود ارتباط بین مؤلفه های یک برنامه بومی ، این اتفاق می افتد.

این حمله همچنین می تواند اتفاق بیفتد اگر TLS دارای آسیب پذیری باشد یا اگر سیستم عامل روتر کاربر به خطر افتاده باشد و DNS را جعل می کند یا TLS را به HTTP کاهش می دهد. PKCE نیاز به یک کد یک بار اضافی برای تولید و ارسال به سرور OAuth دارد. این کد تأیید می کند که درخواست رهگیری یا اصلاح نشده است.

مشخصات پیش نویس OAuth 2. 1 مستلزم آن است که چالش PKCE با هر اعطای کد مجوز استفاده شود، تا در برابر ربوده شدن کد مجوز توسط مهاجم و استفاده برای به دست آوردن یک توکن محافظت شود.

تغییر OAuth 2. 1: URIهای تغییر مسیر باید با استفاده از تطبیق دقیق رشته مقایسه شوند

تغییر مسیر URI باید با استفاده از تطبیق دقیق رشته مطابق با بخش 4. 1. 3 از OAUTH 2. 0 امنیت بهترین روشهای فعلی مقایسه شود

برخی از کمک های OAuth، به ویژه مجوز کد مجوز، با یک یا چند URI تغییر مسیر پیکربندی شده اند. یکی از این موارد پس از شروع کمک مالی توسط مشتری درخواست می شود. پس از موفقیت آمیز بودن کمک هزینه، سرور OAuth مشتری را به URI تغییر مسیر درخواستی ارسال می کند.

اکنون، پشتیبانی از حروف عام در این لیست URI تغییر مسیر راحت خواهد بود. در FusionAuth، ما این درخواست را از افرادی می شنویم که می خواهند محیط توسعه یا CI خود را ساده کنند. هر بار که یک سرور جدید چرخانده می شود، پیکربندی URI تغییر مسیر باید به روز شود تا شامل URI جدید باشد.

به عنوان مثال، اگر یک سیستم CI یک برنامه کاربردی برای هر شاخه ویژگی بسازد، ممکن است نام میزبان dans-sample-application-1551. herokuapp. com را داشته باشد، با فرض اینکه شاخه ویژگی دارای یک اصلاح برای مشکل #1551 باشد. اگر می خواهم با استفاده از اعطای کد مجوز وارد شوم، باید تنظیمات URI تغییر مسیر را برای سرور OAuth خود به روزرسانی کنم تا آن URI تغییر مسیر را در بر بگیرد: https://dans-sample-application-1551. herokuapp. com/oauth-callback.

وقتی ساخت شاخه ویژگی بعدی اتفاق افتاد، مثلاً برای اشکال شماره 1552، باید https://dans-sample-application-1552. herokuapp. com/oauth-callback و غیره را اضافه کنم. بدیهی است که تنظیم URI تغییر مسیر روی یک مقدار wildcard مانند https://dans-sample-application-*. herokuapp. com/oauth-callback آسانتر است. اگر اینطور بود، هر URL مطابق با آن الگو برای سرور OAuth قابل قبول بود.

یک مورد استفاده اضافی برای URI تغییر مسیر کارت وحشی زمانی رخ می دهد که صفحه مقصد نهایی به پارامترهای پویا نیاز دارد، مانند trackingparam=123& specialoffer=abc. اینها معمولاً قبل از شروع فرآیند OAuth به URI تغییر مسیر اضافه می شوند. با این حال، بدون کارت های وحشی، یک URL با پارامترهای پویا با هیچ یک از URI های تغییر مسیر پیکربندی شده مطابقت نخواهد داشت، بنابراین تغییر مسیر با شکست مواجه می شود.

با این حال ، اجازه تطبیق کارت وحشی برای URI تغییر مسیر یک خطر امنیتی است. اگر تطبیق URI تغییر مسیر انعطاف پذیر باشد ، یک مهاجم می تواند کاربر را به یک سرور تغییر مسیر باز کنترل شده توسط آنها و سپس به یک مقصد مخرب ارسال کند. OWASP همچنین در مورد خطرات چنین سرورهای تغییر مسیر باز بحث می کند. در حالی که این حمله نیاز به به خطر انداختن درخواست در برخی شیوه ای دارد ، استفاده از تطبیق دقیق برای URI های تغییر مسیر ، این خطر را از بین می برد زیرا URI تغییر مسیر همیشه یک ارزش شناخته شده است.

OAUTH 2. 1 تغییر: کمک هزینه ضمنی برداشته می شود

کمک هزینه ضمنی ("پاسخ_تایپ = توکن") مطابق بخش 2. 1. 2 از امنیت OAUTH 2. 0 بهترین روشهای فعلی از این مشخصات حذف شده است

کمک هزینه ضمنی هنگام استفاده در یک برنامه تک صفحه ای (SPA) ذاتاً ناامن است. اگر از این کمک هزینه استفاده می کنید ، نشانه دسترسی شما در معرض هر جاوا اسکریپت در مرورگر در کنار آبگرم شما قرار دارد. اگر مراقب نیستید ، یک نشانه دسترسی که در قطعه URL قرار دارد ، در محلی ذخیره می شود ، یا یک کوکی غیر httponly قرار می دهد. در همه موارد ، یک مهاجم که یک نشانه دسترسی را به دست می آورد ، اجازه می دهد به منابع دسترسی پیدا کند که گویی کاربر اصلی هستند. این وضعیت خوبی نیست.

نشانه های دسترسی لزوماً یک بار استفاده نیستند و بسته به نحوه پیکربندی سرور OAuth می توانند از چند دقیقه تا روز زندگی کنند. اگر آنها به سرقت بروند ، منابع محافظت شده دیگر از آنها امن نیستند. شما ممکن است فکر کنید "خوب ، من هیچ JavaScript مخرب در سایت خود ندارم."مطمئنی؟آیا تمام کد خود و وابستگی های آن و وابستگی های آنها و وابستگی های آنها را ممیزی کرده اید؟آیا کد خود را به طور خودکار حسابرسی می کنید؟درختان وابستگی گسترده می توانند به مسائل امنیتی پیش بینی نشده منجر شوند: شخصی یک کتابخانه گره منبع باز را به دست گرفت و کد مخرب را اضافه کرد که میلیون ها بار بارگیری شد.

در اینجا مقاله ای در مورد کمترین روش ناامن برای استفاده از کمک هزینه ضمنی برای یک آبگرم آورده شده است. در این شرایط ، نشانه دسترسی به عنوان یک کوکی httponly به آبگرم ارائه می شود. در پایان اساساً کمک هزینه کد مجوز را بازآفرینی می کند ، و نشان می دهد که چگونه کمک هزینه ضمنی به سادگی نمی توان ایمن شد.

پیش نویس مشخصات OAUTH 2. 1 کمک هزینه ضمنی را حذف می کند. این بدان معنی است که هر نرم افزاری که OAUTH 2. 1 را اجرا می کند ، نیازی به اجرای این کمک هزینه ندارد. اگر از این کمک هزینه در برنامه خود استفاده می کنید ، اگر می خواهید مطابق با OAUTH 2. 1 باشد ، باید آن را جایگزین آن کنید.

OAUTH 2. 1 تغییر: کمک هزینه اعتبار رمز عبور صاحب منبع حذف می شود

کمک هزینه اعتبار رمز عبور صاحب منبع از این مشخصات طبق بخش 2. 4 از OAUTH 2. 0 امنیت بهترین روشهای فعلی حذف شده است

این کمک هزینه به مشخصات OAUTH 2. 0 اضافه شد و چشم به مهاجرت به سرورهای سازگار OAuth آسانتر شد. در این کمک هزینه ، سرور برنامه نام کاربری و رمز عبور (یا سایر اعتبارنامه ها) را دریافت می کند و آن را به سرور OAuth منتقل می کند. در اینجا مقاله ای وجود دارد که هر مرحله از اعطای اعتبار رمز عبور صاحب منبع را تجزیه می کند.

این کمک هزینه اغلب برای برنامه های موبایل بومی استفاده می شود. در حالی که این کمک هزینه با حداقل تغییرات کاربردی ، انتقال به OAUTH را آسانتر کرده است ، اما از الگوی نمایندگی معمولی پیروی نمی کند. از این گذشته ، سرور برنامه دسترسی کامل به اعتبار کاربر دارد ، دقیقاً همان چیزی که OAuth برای جلوگیری از آن طراحی شده است. دیگر نمی توانید کار تأمین اعتبار و داده های کاربران را به سرور OAuth واگذار کنید. با استفاده از این کمک هزینه ، باید اطمینان حاصل کنید که پشتیبان برنامه شما به همان اندازه ایمن است.

اگر با استفاده از این کمک هزینه یک برنامه تلفن همراه دارید ، می توانید مشتری را برای استفاده از کمک هزینه کد مجوز با استفاده از PKCE یا استفاده از سیستم سازگار OAuth 2. 0 خود به روز کنید.

OAUTH 2. 1 تغییر: هیچ نشانه تحمل در رشته پرس و جو وجود ندارد

استفاده از توکن تحمل استفاده از نشانه های تحمل در رشته پرس و جو از URIS طبق بخش 4. 3. 2 از امنیت OAUTH 2. 0 بهترین روشهای فعلی

نشانه های تحمل ، که به عنوان نشانه های دسترسی نیز شناخته می شوند ، امکان دسترسی به منابع محافظت شده را فراهم می کنند و بنابراین باید ایمن شوند. آنها به آنها نشانه های تحمل نامیده می شوند زیرا صرفاً داشتن آنها به شما امکان دسترسی را می دهد. آنها مانند مجموعه ای از کلیدهای خانه هستند.

این روزها ، بیشتر نشانه ها JWT هستند. مشتریان آنها را با اطمینان ذخیره می کنند و سپس از آنها برای برقراری تماس API به سرور برنامه استفاده می کنند. سرور برنامه سپس از توکن برای اطمینان از مشتری تماس با API از مجوزهای مناسب استفاده می کند. هنگامی که برای اولین بار در RFC 6750 تعریف شد ، نشانه ها در هدرها ، جسد پست یا رشته های پرس و جو مجاز بودند. پیش نویس OAUTH 2. 1 ارسال یک توکن حامل در یک رشته پرس و جو را ممنوع می کند.

یک رشته پرس و جو و به طور کلی ، هر رشته ای در URL ، هرگز خصوصی نیست. اجرای JavaScript در یک صفحه می تواند به آن دسترسی پیدا کند. URL یا مؤلفه های آن ممکن است در پرونده های ورود به سیستم سرور ، حافظه پنهان یا تاریخچه مرورگر ضبط شود. به طور کلی ، اگر می خواهید اطلاعات را به صورت خصوصی از طریق اینترنت منتقل کنید ، از چیزی در URL استفاده نکنید. در عوض ، از TLS استفاده کنید و اطلاعات حساس را در یک بدنه پست یا هدر HTTP قرار دهید.

OAUTH 2. 1 تغییر: محدود کردن نشانه های تازه سازی

توکن های تازه کردن باید از نظر فرستنده یا یک بار استفاده شوند یا طبق بخش 4. 12. 2 از OAUTH 2. 0 امنیت بهترین روشهای فعلی

نشانه های تازه به مشتری اجازه می دهد تا نشانه های دسترسی جدید را بدون تأیید مجدد توسط صاحب منبع بازیابی کند. اگر نیاز به دسترسی به یک منبع برای طولانی تر از زندگی یک نشانه دسترسی دارید ، یا اگر به دسترسی نادر نیاز دارید ، نشانه های تازه سازی می توانند به شما کمک کنند. یک نمونه از جایی که ممکن است از یک نشانه تازه استفاده شود ، زمانی است که کاربر برای هفته ها یا ماه ها وارد ایمیل خود می شود. هر بار که یک نشانه دسترسی منقضی می شود ، مشتری می تواند یک نشانه تازه را ارائه دهد و یک نشانه دسترسی جدید دریافت کند.

نشانه های تازه سازی طولانی تر از نشانه های دسترسی هستند و از امتیاز بالاتری برخوردار هستند ، زیرا می توان از آنها برای ایجاد نشانه های دسترسی کاملاً جدید استفاده کرد. بنابراین باید هنگام تأمین یک نشانه تازه ، بیشتر مراقبت کنید. هرگز نشانه های تازه سازی خود را بین دستگاه های مختلف به اشتراک نگذارید.

اگر آنها توسط یک مهاجم به دست بیایند ، می توانند به خواست خود نشان های دسترسی ایجاد کنند. بدیهی است که در آن مرحله ، منبعی که از آنها محافظت می کند دیگر از آن محافظت نمی شود. به عنوان نمونه ای از چگونگی تأمین نشانه های تازه سازی ، در اینجا یک پست با استفاده از کمک هزینه کد مجوز که با استفاده از کوکی های httponly با یک دامنه کوکی محدود ، نشانه های تازه را ذخیره می کند ، می توانید در مورد دسترسی FusionAuth اطلاعات بیشتری کسب کنید.

پیش نویس OAUTH 2. 1 دو گزینه برای نشانه های تازه سازی را فراهم می کند: آنها می توانند یک بار استفاده یا با اتصال رمزنگاری به فرستنده گره خورده باشند.

با استفاده از نشانه های Refresh یک بار ، پس از یک نشانه تازه سازی (آن را به عنوان Token A) برای بازیابی یک نشانه دسترسی جدید استفاده می شود ، نامعتبر می شود. سرور OAUTH ممکن است یک توکن جدید تازه را ارسال کند (آن را به عنوان Token B) B) همراه با نشانه دسترسی درخواست شده ارسال کنید. پس از اتمام نشانه دسترسی تازه تحویل ، مشتری می تواند با استفاده از Token T Token B ، نشانه دسترسی دیگری را درخواست کند ، و نشانه دسترسی جدید و توکن تازه C و غیره را دریافت کند. تغییر در نشانه های Refresh یک بار ممکن است نیاز به تغییر کد مشتری برای ذخیره نشانه جدید تازه در هر نوع تازه از نشانه دسترسی داشته باشد.

گزینه دیگر اطمینان از سرور OAuth است که رمزنگاری رمزنگاری را به مشتری متصل می کند. گزینه های ذکر شده در سند "OAUTH 2. 0 بهترین شیوه های فعلی" شامل اتصال OAuth Token ، تأیید اعتبار متقابل TLS RFC 8705 و DPOP ، از جمله دیگر است. همه این روشهای الزام آور اطمینان حاصل می کنند که درخواست از طرف مشتری که نشانه تازه سازی به آن صادر شده است.

به طور خلاصه ، پیش نویس OAUTH 2. 1 با نیاز به استفاده از یک بار یا استفاده از اثبات رمزنگاری ارتباط با مشتری ، به یک سرور OAuth نیاز دارد. هر دو گزینه از این نشانه های قدرتمند از استفاده توسط یک مهاجم محافظت می کنند.

چه چیزی بدون تغییر است؟

این تغییرات عمده در پیش نویس پیشنهادی OAUTH 2. 1 است. مشخصات OAUTH 2. 1 بر اساس پایه OAUTH 2. 0 RFCS ساخته شده است و تمام رفتاری را که صریحاً حذف نشده یا تغییر نکرده است به ارث می برد. به عنوان مثال ، اعطای اعتبار مشتری ، که اغلب برای ارتباط سرور به سرور استفاده می شود ، هنوز در دسترس خواهد بود.

آیا اکنون می توانید از OAUTH 2. 1 استفاده کنید؟

از هم اکنون ، هیچ چیز "OAUTH 2. 1" وجود ندارد. و پیش نویس مشخصات نهایی نشده است. اما اگر بهترین شیوه های مربوط به امنیت را دنبال می کنید ، می توانید از مزایای این پیش نویس تلفیقی استفاده کنید ، و همچنین برنامه های خود را برای انتشار آن آماده کنید.

هنگام نوشتن یک برنامه مشتری ، از کمک هزینه ضمنی و کمک هزینه اعتبار رمز عبور از منابع منابع خودداری کنید.

اطمینان حاصل کنید که سرور OAUTH شما به دنبال دنبال کردن است:

• استفاده از PKCE هر زمان که از کمک هزینه کد مجوز استفاده می کنید.
• اطمینان حاصل کنید که URI های تغییر مسیر شما با استفاده از مسابقات دقیق رشته مقایسه می شوند ، نه کارت وحشی یا تطبیق بستر.
• اطمینان حاصل کنید که نشانه های تحمل هرگز در رشته پرس و جو حضور ندارند.
• نشانه های تازه سازی خود را محدود کنید ، یا با استفاده از یک بار استفاده یا اینکه آنها را محدود کنید.

چه چیزی بعدی برای OAUTH است

"پیش بینی بسیار دشوار است ، به خصوص اگر در مورد آینده باشد."- Niehls Bohr

OAUTH 2. 1 هنوز در لیست پستی IETF OAUTH بحث شده است. اگر شما علاقه مند به پیگیری یا تأثیرگذاری بر این RFC هستید ، بایگانی بحث را مرور کنید تا سرعت بیشتری پیدا کنید. همچنین می توانید به لیست پستی بپیوندید.

با نگاهی به فراتر از OAUTH 2. 1 ، که همانطور که گفته شد ، هدف آن ادغام بهترین شیوه های امنیتی است اما بیشتر بقیه OAUTH 2. 0 را دست نخورده باقی می گذارد ، یک کارگروه "نسل بعدی" نیز وجود دارد که مجدداً یک پروتکل مذاکره و مجوز کمک مالی را از زمین به بالا بازگرداند. این پروتکل با هدف پوشش همان موارد استفاده OAUTH2 ، اما صریحاً سازگاری عقب مانده را رد می کند:

"اگرچه مصنوعات این کار در نظر گرفته نشده یا انتظار نمی رود که با OAUTH 2. 0 یا OpenID Coect سازگار باشد ، اما این گروه سعی در ساده سازی مهاجرت از OAUTH 2. 0 و OpenID Coect به پروتکل جدید در صورت امکان دارد."

مشخصات GNAP بیشتر از مشخصات OAUTH 2. 1 است.

در این صفحه

لاستیک ها را لگد بزنید و نمونه خود را بسازید

FusionAuth را بدون برنامه یا کارت اعتباری مورد نیاز بارگیری و نصب کنید.