مکانیزم کلی کارکرد

OAuth2 یک پرتکل امنیتی به شمار می‌آید که هدف اصلیش را می‌توان در امن کردن اطلاعات برنامه مورد استفاده‌ی کاربر و محفوظ نگه‌داشتن خود اطلاعات کاربر تعریف کرد.

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

چهار مدل پیاده‌سازی عبارتند از :

1. 1. Client Credentials
2. 2. Password
3. 3. Implict
4. 4. Authorization Code

سامانه احرازهویت ملی براساس مدل 4 یعنی Authorization Code پیاده‌سازی شده‌است که امن‌ترین حالت ممکن به حساب می‌آید و در جلوتر به شرح این مدل می‌پردازیم.

فارغ از هر مدل پیاده‌سازی 4 عنصر همواره در سناریوهای OAuth2 نقش ایفا می‌کنند 

1. 1. Authorization Server : برنامه‌ای است که وظیفه صحت‌سنجی اطلاعات کابران و خود نهادهای‌ متکی (Relying Party) را برعهده دارد و در همه‌ مدل‌های پیاده‌سازی هدف ایجاد توکن و ارسال آن به نهاد متکی برای دسترسی به سرویس‌های مورد نظر می‌باشد.
2. 2. Relying Party : سامانه ای است که قصد استفاده از سرویس‌های محافظت شده توسط Authorization Server را دارد و برای این کار باید با برنامه‌ی احرازهویت تعامل کند که در صورت درست بودن اطلاعات هویتی توکن دریافت می‌کند. این عبارت در فارسی به نهاد متکی برگردان شده است و البته در برخی مستندات برای سهولت استفاده با عبارت «کسب و کار» جایگزین شده است.د
3. 3. Resource Server : سرویس‌هایی که قرار است از آنها محافظت شود تا هر برنامه/شخصی نتواند از آنها استفاده کند. 
4. 4. User : کاربری است که با برنامه‌ی نهادمتکی در تعامل است و اطلاعات خود را باید به طریقی یا به خود برنامه نهادمتکی یا Authorization Server بدهد تا بتواند به صورت کامل از برنامه استفاده کند.

غایت تمام این مدل‌ها تولید توکن JWT می‌باشد که به شرح آن می‌پردازیم.

1. 1. خود این توکن شامل 3 قسمت header،payload و signature می‌باشد
2. 2. signature : بیان کننده‌ی توکن امضا شده است و هدف این کار ایجاد قابلیت عدم انکار می‌باشد (یعنی متوجه بشویم این توکن را چه کسی تولید کرده است).
3. 3. payload : بدنه‌ی توکن را تشکیل می‌دهد و شامل اطاعات موردنیاز می‌باشد که به هرکدام از این اطلاعات claim گفته می‌شود و claimهای رایج و ضروری در بدنه‌ی توکن عبارتند از :
   1. 1. exp : مدت زمانی که طول می‌کشد تا توکن منقضی شود.
   2. 2. jti : شامل شناسه یکتا جهت تفکیک توکن‌های تولید شده از هم می‌باشد 
   3. 3. scopes : شامل سطح دسترسی است که این توکن دارا می‌باشد.
4. 4. header: شامل مدل رمزنگاری است که توکن بر اساس آن ساخته شده است.

شرح مدل Authorization Code

فرض شود که یک سایت فروشگاه اینترنتی (Relying Party) موجود می‌باشد و کاربر (User) قصد خرید کالایی را دارد و این سایت نیازدارد که قبل از فرستادن کاربر به درگاه خرید هویتش را شناسایی کند پس سرویس خرید (Resource Server) یک سرویس محافظت‌شده به‌حساب می‌آید.

حال نهاد متکی به دلیل آنکه خودش به بانک اطلاعاتی کاربرها دسترسی ندارد کاربر را به سامانه مرکزی احرازهویت ملی (Authorization Server) ریدایرکت می‌کند تا آنجا شناسایی شود.

اولین اتفاقی که قبل از مشاهده صفحه‌ی لاگین برای کاربر رخ می‌دهد صحت سنجی خود نهادمتکی می‌باشد و  بعد از تایید اطلاعات نهاد متکی به کاربر صفحه‌ی لاگین نشان داده‌‌می‌شود و کاربر می‌تواند مراحل احرازهویت را انجام می‌دهد سپس در نهایت به نهاد متکی موردنظر ریدارکت می‌شود.

در این ریدارکت فیلدی به نام کد روی درخواست به حالت query param قرار می‌گیرد که برای آخرین قسمت فرآیند یعنی دریافت توکن الزامی‌است.

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

برای بازگشایی توکن در سمت نهاد متکی نیاز به کلید عمومی است که هر نهاد متکی نیاز‌دارد در ابتدای شروع برنامه‌ی خودش این کلید را دریافت‌کند. آدرس دریافت کلید عمومی در مستندات راهنمای اتصال آورده شده‌است.

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

به طبع در صورت منقضی‌شدن توکن نهادمتکی کاربر را به سامانه احرازهویت ملی هدایت می‌کند.

در شکل زیر فرآیند به تصویر کشیده شده‌است.