توجه داشته باشید. ترجمه: این مقاله عالی توسط Okta نحوه عملکرد OAuth و OIDC (OpenID Connect) را به روشی ساده و واضح توضیح می دهد. این دانش برای توسعه دهندگان، مدیران سیستم و حتی "کاربران عادی" برنامه های کاربردی وب محبوب مفید خواهد بود که به احتمال زیاد داده های محرمانه را با سایر سرویس ها نیز مبادله می کنند.
در عصر حجر اینترنت، به اشتراک گذاری اطلاعات بین سرویس ها آسان بود. شما به سادگی لاگین و رمز عبور خود را از یک سرویس به سرویس دیگر دادید تا او وارد حساب شما شده و هر اطلاعاتی را که نیاز داشت دریافت کند.
"حساب بانکی خود را به من بدهید." "ما قول می دهیم که همه چیز با رمز عبور و پول خوب خواهد بود. این صادقانه است، صادقانه!" *هی هی*
وحشت! هیچ کس نباید از کاربر بخواهد نام کاربری و رمز عبور را به اشتراک بگذارد، اعتبارنامه، با یک سرویس دیگر هیچ تضمینی وجود ندارد که سازمانی که پشت این سرویس قرار دارد، داده ها را ایمن نگه دارد و اطلاعات شخصی بیش از حد لازم را جمع آوری نکند. ممکن است احمقانه به نظر برسد، اما برخی از اپلیکیشن ها همچنان از این تمرین استفاده می کنند!
امروزه یک استاندارد واحد وجود دارد که به یک سرویس اجازه می دهد تا به طور ایمن از داده های سرویس دیگر استفاده کند. متأسفانه، چنین استانداردهایی از اصطلاحات و اصطلاحات زیادی استفاده می کنند که درک آنها را پیچیده می کند. هدف از این مطالب توضیح نحوه کار آنها با استفاده از تصاویر ساده است (به نظر شما نقاشی های من شبیه نقاشی های کودکانه است؟ اوه خوب!).
به هر حال، این راهنما به صورت ویدئویی نیز موجود است:
خانم ها و آقایان، خوش آمدید: OAuth 2.0
یک استاندارد امنیتی است که به یک برنامه اجازه می دهد تا مجوز دسترسی به اطلاعات در برنامه دیگر را کسب کند. ترتیب مراحل صدور مجوز [اجازه] (یا رضایت [رضایت]) اغلب تماس می گیرند مجوز [مجوز] یا حتی مجوز تفویض شده [مجوز تفویض شده]. با استفاده از این استاندارد، به یک برنامه اجازه می‌دهید تا داده‌ها را بخواند یا از عملکردهای یک برنامه دیگر از طرف شما بدون دادن رمز عبور به آن استفاده کند. کلاس!
به عنوان مثال، فرض کنید سایتی به نام «پاناس بدشانس روز» را کشف کردید. [ جناس وحشتناک روز ] و تصمیم به ثبت نام در آن برای دریافت جناس روزانه به صورت پیامک تلفنی گرفت. شما واقعاً سایت را دوست داشتید و تصمیم گرفتید آن را با همه دوستان خود به اشتراک بگذارید. پس از همه، همه جناسهای خزنده را دوست دارند، درست است؟
جناس تاسف بار روز: در مورد مردی که نیمه چپ بدنش را از دست داد شنیده اید؟ حالا او همیشه حق دارد!» (ترجمه تقریبی، زیرا اصل جناس خاص خود را دارد - تقریباً ترجمه.)
واضح است که نوشتن برای هر فرد از لیست مخاطبین یک گزینه نیست. و اگر حتی اندکی شبیه من هستید، برای جلوگیری از کارهای غیرضروری تمام تلاش خود را خواهید کرد. خوشبختانه، جناس وحشتناک روز می تواند تمام دوستان شما را به تنهایی دعوت کند! برای انجام این کار، شما فقط باید دسترسی به ایمیل مخاطبین خود را باز کنید - خود سایت برای آنها دعوت نامه ارسال می کند (قوانین OAuth)!
«همه جناس را دوست دارند! - قبلا وارد شده اید؟ «آیا می‌خواهید به وب‌سایت Terrible Pun of the Day اجازه دهید به لیست مخاطبین شما دسترسی داشته باشد؟ - متشکرم! از این به بعد، ما هر روز برای همه کسانی که می شناسید، تا پایان زمان یادآوری ارسال خواهیم کرد! تو بهترین دوستی!"
- سرویس ایمیل خود را انتخاب کنید.
- در صورت لزوم، به سایت ایمیل بروید و وارد حساب کاربری خود شوید.
- به Terible Pun of the Day اجازه دسترسی به مخاطبین خود را بدهید.
- به سایت جناس وحشتناک روز برگردید.
در صورتی که نظر خود را تغییر دهید، برنامه هایی که از OAuth استفاده می کنند راهی برای لغو دسترسی نیز ارائه می دهند. هنگامی که تصمیم گرفتید دیگر نمی‌خواهید مخاطبین خود را با بازی وحشتناک روز به اشتراک بگذارید، می‌توانید به سایت ایمیل بروید و سایت جناس را از لیست برنامه‌های مجاز حذف کنید.
جریان OAuth
ما به تازگی از آنچه معمولاً نامیده می شود عبور کرده ایم جریان [جریان] OAuth. در مثال ما، این جریان شامل مراحل قابل مشاهده و همچنین چندین مرحله نامرئی است که در آن دو سرویس بر روی تبادل امن اطلاعات توافق می کنند. مثال قبلی Terrible Pun of the Day از رایج ترین جریان OAuth 2.0 استفاده می کند که به عنوان جریان "کد مجوز" شناخته می شود. [جریان "کد مجوز"].
قبل از پرداختن به جزئیات نحوه عملکرد OAuth، اجازه دهید در مورد معنای برخی از اصطلاحات صحبت کنیم:
- صاحب منبع:
این شما هستید! شما مالک اعتبار، داده‌هایتان هستید و تمام فعالیت‌هایی را که ممکن است در حساب‌هایتان انجام شود کنترل می‌کنید. - مشتری:
برنامه ای (به عنوان مثال، سرویس وحشتناک جنای روز) که می خواهد به نمایندگی از صاحب منبع'a. - سرور مجوز:
برنامه ای که می داند صاحب منبع'a و در آن u صاحب منبعیک حساب کاربری دارید. - سرور منبع:
رابط برنامه نویسی برنامه (API) یا سرویسی که مشتری می خواهد از طرف استفاده کند صاحب منبع'a. - تغییر مسیر URI:
لینکی که سرور مجوز تغییر مسیر خواهد داد صاحب منبعو پس از اعطای اجازه مشتریدر گاهی اوقات از آن به عنوان "URL برگشت به تماس" یاد می شود. - نوع پاسخ:
نوع اطلاعاتی که انتظار می رود دریافت شود مشتری. رایج ترین نوع پاسخ'اهم کد است، یعنی مشتری انتظار دریافت دارد کد مجوز. - حوزه:
این شرح مفصلی از مجوزهای مورد نیاز است مشتری'y، مانند دسترسی به داده ها یا انجام برخی اقدامات. - رضایت:
سرور مجوز طول می کشد دهیدرخواست کرد مشتریاوم، و می پرسد صاحب منبعالف، آیا او آماده ارائه است؟ مشتریمجوزهای مناسب را داشته باشند. - شناسه مشتری:
این شناسه برای شناسایی استفاده می شود مشترییک در سرور مجوز'e. - راز مشتری:
این رمزی است که فقط شناخته شده است مشتریتو و سرور مجوزدر این به آنها اجازه می دهد تا اطلاعات را به صورت خصوصی به اشتراک بگذارند. - کد مجوز:
کد موقت با مدت اعتبار کوتاه که مشتری فراهم می کند سرور مجوزدر ازای دسترسی به رمز. - دسترسی به رمز:
کلیدی که مشتری برای برقراری ارتباط با آن استفاده می کند سرور منبعاوم نوعی نشان یا کارت کلیدی که فراهم می کند مشتری"مجوز درخواست داده یا انجام اقدامات را داشته باشید سرور منبعمن از طرف شما
یادداشت: گاهی اوقات سرور مجوز و سرور منبع یک سرور هستند. با این حال، در برخی موارد، این سرورها ممکن است متفاوت باشند، حتی اگر به یک سازمان تعلق نداشته باشند. به عنوان مثال، سرور مجوز ممکن است یک سرویس شخص ثالث مورد اعتماد سرور منبع باشد.
اکنون که مفاهیم اصلی OAuth 2.0 را پوشش دادیم، بیایید به مثال خود برگردیم و نگاهی دقیق‌تر به آنچه در جریان OAuth می‌افتد بیاندازیم.
- شما، صاحب منبع، می خواهید سرویس جناس وحشتناک روز را ارائه دهید (مشتریy) به مخاطبین خود دسترسی داشته باشید تا بتوانند برای همه دوستان شما دعوت نامه ارسال کنند.
- مشتری مرورگر را به صفحه هدایت می کند سرور مجوزa و در پرس و جو قرار دهید شناسه مشتری, تغییر مسیر URI, نوع پاسخ و یک یا چند دهی (مجوزها) نیاز دارد.
- سرور مجوز شما را تأیید می کند و در صورت لزوم از شما نام کاربری و رمز عبور می خواهد.
- سرور مجوز یک فرم را نمایش می دهد رضایت (تأییدات) با لیستی از همه دهیدرخواست کرد مشتریاوم شما موافقت می کنید یا رد می کنید.
- سرور مجوز شما را به سایت هدایت می کند مشتری"الف، با استفاده از تغییر مسیر URI با کد مجوز (کد مجوز).
- مشتری مستقیم با سرور مجوز'اهم (با دور زدن مرورگر صاحب منبعالف) و با خیال راحت ارسال می کند شناسه مشتری, راز مشتری и کد مجوز.
- سرور مجوز داده ها را بررسی می کند و با آن پاسخ می دهد دسترسی به رمز'om (توکن دسترسی).
- اکنون مشتری می توانید استفاده کنید دسترسی به رمز برای ارسال درخواست به سرور منبع برای دریافت لیستی از مخاطبین
شناسه مشتری و راز
مدتها قبل از اینکه به Terible Pun of the Day اجازه دسترسی به مخاطبین شما را بدهید، مشتری و سرور مجوز یک رابطه کاری برقرار کرده بودند. سرور مجوز شناسه مشتری و راز مشتری (گاهی اوقات فراخوانی می شود) تولید می کند شناسه برنامه и برنامه راز) و آنها را برای تعامل بیشتر در OAuth به مشتری ارسال کرد.
"- سلام! من دوست دارم با شما کار کنم! - حتما مشکلی نیست! در اینجا شناسه مشتری و راز شما آمده است!»
این نام نشان می دهد که Client Secret باید مخفی بماند تا فقط مشتری و سرور مجوز آن را بدانند. از این گذشته ، با کمک او است که سرور مجوز صحت مشتری را تأیید می کند.
اما این همه چیز نیست... لطفاً به OpenID Connect خوش آمدید!
OAuth 2.0 فقط برای طراحی شده است مجوز - برای دسترسی به داده ها و عملکردها از یک برنامه به برنامه دیگر. (OIDC) یک لایه نازک در بالای OAuth 2.0 است که جزئیات ورود و نمایه کاربری را که به حساب کاربری وارد شده است اضافه می کند. سازماندهی یک جلسه ورود اغلب به عنوان نامیده می شود احراز هویت [احراز هویت]، و اطلاعات مربوط به کاربر وارد شده به سیستم (به عنوان مثال در مورد صاحب منبعه) - اطلاعات شخصی [هویت]. اگر سرور مجوز از OIDC پشتیبانی می کند، گاهی اوقات به آن اشاره می شود ارائه دهنده داده های شخصی [ارائه دهنده هویت]زیرا فراهم می کند مشتریاطلاعاتی در مورد صاحب منبع'e.
OpenID Connect به شما اجازه می دهد تا سناریوهایی را پیاده سازی کنید که در آن یک ورود به سیستم می تواند در چندین برنامه استفاده شود - این رویکرد همچنین به عنوان شناخته شده است. ورود به سیستم واحد (SSO). به عنوان مثال، ممکن است یک برنامه از یکپارچه سازی SSO با شبکه های اجتماعی مانند فیس بوک یا توییتر پشتیبانی کند و به کاربران این امکان را می دهد تا از حسابی که قبلاً دارند و ترجیح می دهند استفاده کنند، استفاده کنند.
جریان (جریان) OpenID Connect مانند مورد OAuth به نظر می رسد. تنها تفاوت این است که در درخواست اولیه، محدوده خاص استفاده شده است openid، - آ مشتری در نهایت شبیه می شود دسترسی به رمزو شناسه شناسه.
درست مانند جریان OAuth، دسترسی به رمز در OpenID Connect، این مقداری است که مشخص نیست مشتریدر از دیدگاه مشتری'a دسترسی به رمز نشان دهنده رشته ای از کاراکترها است که به همراه هر درخواست ارسال می شود سرور منبع'y، که تعیین می کند آیا توکن معتبر است یا خیر. شناسه شناسه چیزی کاملا متفاوت را نشان می دهد.
شناسه توکن JWT است
شناسه شناسه یک رشته فرمت شده خاص از کاراکترها به نام JSON Web Token یا JWT است (گاهی اوقات توکن های JWT مانند "jots" تلفظ می شوند). برای ناظران بیرونی، JWT ممکن است به نظر بیهوده غیرقابل درک باشد، اما مشتری می تواند اطلاعات مختلفی از جمله ID، نام کاربری، زمان ورود، تاریخ انقضا را از JWT استخراج کند شناسه شناسهالف، وجود تلاش‌هایی برای تداخل با JWT. داده های داخل شناسه شناسه'a نامیده می شوند برنامه های کاربردی [ادعاها].
در مورد OIDC نیز یک روش استاندارد وجود دارد که توسط آن مشتری ممکن است اطلاعات بیشتری در مورد فرد درخواست کند [هویت] از سرور مجوزبرای مثال، یک آدرس ایمیل با استفاده از دسترسی به رمز.
درباره OAuth و OIDC بیشتر بیاموزید
بنابراین، به طور خلاصه نحوه کار OAuth و OIDC را بررسی کردیم. آماده کاوش عمیق تر هستید؟ در اینجا منابع اضافی وجود دارد که به شما کمک می کند درباره OAuth 2.0 و OpenID Connect بیشتر بدانید:
مثل همیشه لطفا نظر بدید برای اطلاع از آخرین اخبار ما، مشترک شوید и Okta برای توسعه دهندگان!
PS از مترجم
در وبلاگ ما نیز بخوانید:
- «"؛
- «"؛
- «"؛
- «'.
منبع: www.habr.com