در این مجموعه مطالب از OAuth و OpenID Connect، مفاهیم Identity management را بررسی خواهیم کرد.
جریان Identity management به موضوع شناسایی هویت ها می پردازد و از دو نیاز Authentication و Authorization در نرم افزار شکل گرفته است. مباحث authentication و authorization در اکثر اپلیکیشن های امروزی وجود دارند و مانند حوزه های دیگر از نرم افزار، دچار تکامل و تحول شده اند.
مفهوم authentication به موضوع شناسایی یک هویت و مفهوم authorization به موضوع دسترسی های یک هویت در نرم افزار می پردازد. این نیازها از ابتدای تاریخچه توسعه نرم افزارها وجود داشته اند.
در اولین نسل از توسعه نرم افزار، هر نرم افزار یک دیتابیس داشت که شامل لیستی از کاربران، نقش ها و دسترسی های مربوطه بود. کاربران بر اساس credential، شناسایی می شدند و دسترسی آن ها نیز با استفاده از identity مشخص می شد. مشکلی که وجود داشت، به تعداد هر نرم افزار، اطلاعات کاربری بصورت مجزا نگهداری می شد. بنابراین سازمان ها و تیم های نرم افزاری به سمت Central Repositoryها حرکت کردند.
در مدل central repository، یک اپلیکیشن داریم که شامل کاربران، نقش ها و دسترسی ها می باشد و اپلیکیشن های دیگر از طریق آن به شناسایی کاربران می پردازند. بنابراین کاربر نیازی ندارد که تعداد زیادی یوزر و پسورد نگهداری کند. این روال به خاطر مشکلات امنیتی که داشت که شامل دسترسی تمام اپلیکیشن ها به اطلاعات کاربری می شد، تغییر کرد و پس از آن ایده Federated Identity مطرح شد.
در مدل federated identity، اپلیکیشن ها می توانند عملیات authentication را از طریق یک service provider انجام دهند. یک هویت یکپارچه در موقعیت identity management داریم که به اپلیکیشن های دیگر سرویس می دهد. پروتکل های SAML 2.0 که در سال 2003 مطرح شد و بعد از آن WS-Federation به این موضوع می پردازند. این مباحث بیشتر در سیستم های enterprise و سازمانی مورد استفاده قرار می گرفتند و شامل کاربران آن حوزه می شد.
در حال حاضر که استفاده از APIها و Social networkها مرسوم شده است، نیازهای جدیدی در حوزه identity management نیز مطرح شده است. پروتکل هایی مانند OpenID، در این راستا و در یک بازه زمانی مورد استفاده قرار گرفتند. شما می توانستید با یک OpenID Account، در اپلیکیشن های مختلف login کنید.
بعد از آن OAuth 2.0 مطرح شد که در حوزه delegated authorization فعالیت می کند. به خاطر اتفاقاتی که برای OAuth افتاد که در آینده در مورد آن صحبت خواهیم کرد، پروتکل OpenID Connect به عنوان یک لایه برروی OAuth 2.0 مطرح شد که جزء رایج ترین پروتکل هایی است که در حوزه identity management استفاده می شود.
در معرفی OAuth 2.0 از اصلاح delegated authorization استفاده کردیم که به آن می پردازیم.
در یک سناریو، برای مثال یک سرویس مانند instagram را در نظر بگیرید که عکس های خود را در آن قرار می دهیم. اسم آن را Resource Server می گذاریم. همچنین یک وبسایت را در نظر بگیرید که از طریق آپلود کردن تصاویر در آن، بر روی تصاویر effect اجرا می شود و به ما خروجی می دهد. اسم آن را Client می گذاریم. در client این امکان را داریم که عکس های خود را آپلود کنیم و یا client از تصاویر آپلود شده ما در اینستاگرام استفاده کند.
در این use case، یک کاربر نیز وجود دارد که در OAuth 2.0 به عنوان Resource Owner شناخته می شود.
یک سرویس دیگر هم وجود دارد که identity management را پیاده سازی می کند و آن را به عنوان Authorization Server می شناسیم.
در این سناریو، client به نمایندگی از owner، قصد استفاده از resource در resource server را دارد. یک کاربر که در نقش owner می باشد، به client اجازه دسترسی به resource را می دهد. به این جریان authorization delegation گفته می شود. بنابراین موضوع OAuth به خاطر authorization delegation اتفاق افتاده است که در نتیجه آن، کاربر کارهای خود را در یک زمان و حوزه دسترسی مشخص، به یک سرویس دیگر می سپارد.
در OAuth، مفهومی به نام Scope وجود دارد که کاربر در یک حوزه مشخصی به کلاینت دسترسی می دهد. scope نهایی از طریق صفحه ای به نام Consent Screen توسط کاربر مشخص می شود.
در این سناریو و از طریق client، از دو روش موجود آپلود تصاویر و خواندن تصاویر از اینستاگرام، کاربر خواندن تصاویر از اینستاگرام را انتخاب می کند. client کاربر را به authorization server هدایت می کند.
آدرسی که client برای هدایت کاربر به authorization server ایجاد می کند دارای تعدادی پارامتر است. پارامتر redirect_uri، مسیر بازگشت از authorization server به client را مشخص می کند. پارامتر client_id، مشخصه آن client در authorization server است که جزو الزامات client است. پارامتر response_type با مقدار code از پارامترهای دیگر است که دارای انواع مختلفی می باشد و در بخش Grant Types به آن ها می پردازیم. پارامتر scope که ما آن ها را تعیین می کنیم و با توجه به تنظیمات، در اینجا شامل مقادیر profile ،openid و read-pictures می باشد. در حقیقت، client مشخص کرده است که profile ،identifier و دسترسی خواندن تصاویر را نیاز دارد. پارامتر state، برای نگهداری آخرین وضعیت کاربر در client استفاده می شود. همچین جلوگیری از حملات cross-site request forgery نیز یکی دیگر از کاربردهای آن می باشد.
سپس authorization server کاربر را شناسایی می کند و در صورت مجاز بودن، صفحه consent screen را به او نشان می دهد. بعد از اینکه کاربر اجازه داد، یک Access Token به client برمی گردد. access token یک رشته است که در آن زمان انقضا و حوزه دسترسی مشخص است و در یک authority دارای اعتبار است.
از این لحظه به بعد، client از طریق access token به resource server درخواست می زند و resourceها را دریافت می کند.
در بعضی از سناریوها، موضوع Offline Access هم وجود دارد. برای مثال می توانیم اپلیکیشن های فیس بوک را مثال بزنیم که با وجود آفلاین بودن کاربران، از طرف آن ها پست ایجاد می کردند. بنابراین از طریق یک token دیگر به نام Refresh Token، امکان offline access برای client ایجاد می شود. client با استفاده از refresh token می تواند زمان access token خود را تمدید کند.
یکی از اشتباهات رایج که برنامه نویسان در استفاده از OAuth و OIDC انجام می دهند، استفاده از scope به عنوان permission می باشد. در حالی که scope، حوزه دسترسی client را مشخص می کند. زمانی که در مورد permission صحبت می کنیم، در اصل در مورد یک user صحبت می کنیم که resource owner می باشد. وقتی در مورد scope صحبت می کنیم، به حوزه دسترسی client به عنوان user در یک resource server می پردازیم.
در حال حاضر که OAuth فراگیر شده و جاهای مختلف از آن استفاده می شود، افراد و کمپانی هایی وجود دارند که از OAuth به خوبی استفاده نمی کنند و قصد دارند از طریق آن authentication را شبیه سازی کنند.
برای مثال در یک سناریو، کاربر وارد یک سایت می شود که دارای لاگین از طریق فیس بوک می باشد. کاربر اقدام به لاگین از طریق فیس بوک می کند و client با scope ایمیل، کاربر را به فیس بوک به عنوان یک authorization server هدایت می کند. بعد از اینکه کاربر در فیس بوک credential خود را وارد کند، یک access token که شامل ایمیل کاربر و اطلاعات دیگر می باشد، به client برمی گردد. و client در نتیجه آن token، کاربر را authenticate می کند و برای آن یک حساب ایجاد می کند.
در نتیجه از پروتکلی که برای authorization طراحی شده است، برای authentication استفاده می شود که صحیح نیست.
زمانی که استفاده نادرست از OAuth رواج پیدا کرد، یک specification به نام OpenID Connect مطرح شد که یک لایه برروی پروتکل OAuth 2.0 می باشد. OIDC به clientها اجازه می دهد که هویت کاربران را شناسایی کنند. بنابراین OAuth فقط بر روی دسترسی افراد تمرکز داشت و مساله identity در آن دیده نشده بود. OIDC بر روی OAuth نوشته شد که به موضوع identity و هویت افراد می پردازد. در نتیجه در OIDC غیر از access token، یک موجود دیگر به نام Id Token هم ایجاد شد که در مورد هویت کاربر می باشد.
در بخش بعدی به بررسی جزئیات بیشتری از authorization delegation می پردازیم.
