در این مقاله به شرح کاملی از اعتبارسنجی براساس رمزنگاری OWINیا (Katana) و OAuth می پردازیم.OWIN یا (Open Web Inteface for .NET) روشی منبع باز (Open Source) است که لایه های انتزاعی بین وب سرور و اجزای نرم افزار را تشریح می کند.

OWINیا(Open Web Inteface for .NET) روشی منبع باز (Open Source) است که لایه های انتزاعی بین وب سرور و اجزای نرم افزار را تشریح می کند. OWIN یک رابط استاندارد بین وب سرور .NET و برنامه های کاربردی تحت وب است. هدف اصلی OWIN جدا کردن سرور و برنامه های کاربردی، توسعه نوید بخش از اجزای نرم افزاری کوچک و متمرکز است که بخشی از فرآیند خطی که سرور می تواند مسیر ورود HTTP را درخواست دهد، است. OWIN یک مشخصه است، نه یک برنامه اجرایی.

Katana اجزائی منبع باز برای ساختن و میزبانی برنامه های کاربردی وب مبتنی بر OWIN است که اجرای ویژگی های OWIN را فراهم می کند. این بخش توسط گسترش فن آوری های گروه مایکروسافت حفظ می شود.

چارچوب احراز هویت OAuth یک برنامه کاربردی سوم شخص را برای بدست آوردن دسترسی محدود به خدمات HTTP قادر می سازد. یکی از الگوهای مشترکی که برای اعتبارسنجی در برنامه کاربردی استفاده می شود یک مدل OAuth Resource Owner Flow است.

در ادامه اجزای اصلی این روش برنامه کاربردی را می بینید:

Resource server -1: از منابع نگهداری می کند و در مقابل از دسترسی های احراز هویت منابع محافظت می کند.

2-  Resource owner: منابع را براساس چیزی که نیاز است درخواست می دهد.

Authorization server -3: سروری است که هویت صاحب منبع را اعتبارسنجی می کند و سطح دسترسی داده شده به کاربران را مورد بررسی قرار می دهد.

Client -4: برنامه ای کاربردی است که درخواست دسترسی به یک منبع از صاحب منابع است.

نگاه کلی به جریان اعتبارسنجی صاحبان منابع:

صاحب منابع می تواند سطح دسترسی را برای کاربر و مشتری تعریف کند. صاحب منبع سطح دسترسی کاربری و سطح دسترسی مشتری را به Client تحویل می دهد. Client سطح دسترسی را به احراز هویت سرور ارسال می کند. احراز هویت سرور، سطح دسترسی را تائید کرده و یک سطح دسترسی رمزگذاری شده تولید می کند. این سطح دسترسی به Client باز می گردد.

در درخواست بعدی، Client از این سطح دسترسی برای ایجاد درخواست به سرور منبع استفاده می کند. سرور منبع برای پذیرفتن سطح دسترسی طراحی شده است تا این سطح دسترسی را برای معتبر ساختن سطح دسترسی به احراز هویت سرور ارسال کند. براساس پاسخ احراز هویت سرور، سرور منبع، منبعی را فراهم می کند و یا درخواست را انکار می کند.

برای یک پروژه کوچک می توانیم احراز هویت سرور را با سرور منبع ترکیب کنیم.

سازوگار اعتبارسنجی تخصیص داده شده:

احراز هویت سرور مسئول اعتبارسنجی رمز ورودی از سمت مشتری است. در واقع این امر شامل 3 مورد زیر برای اعتبارسنجی ورودی است.

1- رمزگذاری به خوبی قالب بندی شده است.

2- رمزگذاری از قدرت بالایی برخوردار است.

3- رمزگذاری برای برنامه کاربردی فعلی است.

قالب بندی خوب:

وقتی میگوییم که رمزگذاری به خوبی قالب بندی شده است، رمزگذاری شامل موارد زیر می شود.

1- رمزگذاری بر طبق قالب موردنظر به درستی قالب بندی شده است.

2- رمزگذاری حاوی یک تاریخ پایان است، پس با مدت زمان معتبری دریافت شده است.

3- رمزگذاری زمینه سازی نشده است.

اگر یک رمزگذاری بنظر خوب انجام شود و به مرحله بعدی انتقال یابد، موارد بالا برقرار خواهند بود، در غیر اینصورت OAuth احراز هویت را رد می کند.

براساس اعتبارسنجی موردنظر:

رمزگذاری برای تبلیغ واضح و روشن منشاء آن ها که ممکن است، طراحی شده است. در فرایند مورد استفاده قرار می گیرد. که هر دو در کنار هم استفاده شده اند.

1- تائید امضاء: کلید مورد استفاده برای ثبت رمز صادر شده، منحصر به مقام صادر کننده است. حال رمز با یک کلید که رمز سوال ثبت شده است

2- ارزش صادر کننده: هر منبعی دارای مشخصات منحصر به فردی است. فرمت های مختلف رمز برای اطلاعات در مکان های خاص استفاده می شود، ماند یک نوع ادعای خاص.

کلید تائید امضاء و مقدار ID صادر کننده به عنوان بخشی از مکانیسم تبلیغات پشتیبانی شده توسط منبع موجود هستند، مانند metadata ،  اسناد کشف شده.

منتخب برای برنامه فعلی:

در این فرایند بخش بندی سیستم، پروتکل استفاده شده برای تعیین را چک می کند تا رمز با برنامه کاربردی فعلی یکی باشد.

OAuth با فراهم کردن رمز تائید شده مشتری را برای تائید منابع حفاظت شده قادر می سازد. احراز هویت سرور مسئول صادر  نمودن رمز با موافقت صاحب منبع است. یک رمز در چارچوب احراز هویت OAuth 2.0 به عنوان رشته مشخص شده است. این مستقیما نشان دهنده مجور دسترسی صادر شده به مشتری به جای استفاده از اعتبار صاحب منبع است. مشتری از رمز تائید شده برای تائید منابع محافظت شده ی سرور منبع استفاده می کند.