مقدمه ای بر OAuth 2.0

شما در حال مشاهده اسناد Apigee Edge هستید.
به مستندات Apigee X بروید . اطلاعات

صفحه اصلی OAuth : برای مشاهده سطح بالای راهنمایی OAuth که ارائه می کنیم، به صفحه اصلی OAuth مراجعه کنید .

این موضوع یک نمای کلی از OAuth 2.0 در Apigee Edge ارائه می دهد.

OAuth 2.0 چیست؟

کتاب ها، وبلاگ ها و سایت های زیادی به OAuth 2.0 اختصاص داده شده است. ما به شدت توصیه می کنیم که با بررسی مشخصات IETF OAuth 2.0 شروع کنید. در اینجا تعریف OAuth 2.0 از خود مشخصات OAuth 2.0 IETF آمده است:

«چارچوب مجوز OAuth 2.0 به یک برنامه شخص ثالث امکان دسترسی محدود به یک سرویس HTTP را می دهد، چه از طرف مالک منبع با هماهنگ کردن یک تعامل تأیید بین مالک منبع و سرویس HTTP، یا با اجازه دادن به برنامه شخص ثالث. از طرف خودش دسترسی پیدا کند."

نکته اصلی که باید بدانید این است که OAuth 2.0 راهی را برای برنامه ها فراهم می کند تا دسترسی محدودی به منابع محافظت شده کاربر (به حساب بانکی یا هر اطلاعات حساس دیگری که کاربر ممکن است بخواهد از یک برنامه به آن دسترسی پیدا کند) بدون نیاز به کاربر برای فاش کردن اعتبار ورود خود به برنامه.

جریان OAuth 2.0

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

اصطلاحاتی که باید بدانید

• مشتری: همچنین به نام "برنامه". این می تواند یک برنامه در حال اجرا بر روی یک دستگاه تلفن همراه یا یک برنامه وب سنتی باشد. این برنامه از طرف مالک منبع، درخواست هایی را برای دارایی های محافظت شده به سرور منبع ارائه می کند. مالک منبع باید به برنامه اجازه دسترسی به منابع محافظت شده را بدهد.
• صاحب منبع: به آن "کاربر نهایی" نیز می گویند. به طور کلی این شخص (یا موجودیت دیگری) است که می تواند به یک منبع محافظت شده دسترسی دهد. برای مثال، اگر برنامه‌ای نیاز به استفاده از داده‌های یکی از سایت‌های رسانه اجتماعی شما داشته باشد، شما مالک منبع هستید -- تنها فردی که می‌تواند به برنامه اجازه دسترسی به داده‌های شما را بدهد.
• سرور منبع: سرور منبع را به عنوان سرویسی مانند فیس بوک، گوگل یا توییتر در نظر بگیرید. یا یک سرویس منابع انسانی در اینترانت شما؛ یا یک سرویس شریک در اکسترانت B2B شما. هر زمان که برای پردازش درخواست‌های API نیاز به تأیید اعتبار نشانه OAuth باشد، Apigee Edge یک سرور منبع است. سرور منبع قبل از اینکه منابع محافظت شده را به برنامه ارائه کند به نوعی مجوز نیاز دارد.
• سرور مجوز: سرور مجوز مطابق با مشخصات OAuth 2.0 پیاده سازی شده است و مسئول اعتبار اعطای مجوز و صدور نشانه های دسترسی است که به برنامه امکان دسترسی به داده های کاربر در سرور منبع را می دهد. شما می توانید "نقاط پایانی نشانه" را در Apigee Edge پیکربندی کنید، در این صورت Edge نقش سرور مجوز را بر عهده می گیرد.
• اعطای مجوز: به برنامه اجازه می‌دهد تا رمز دسترسی را از طرف کاربر نهایی بازیابی کند. OAuth 2.0 چهار "نوع کمک مالی" خاص را تعریف می کند. « انواع کمک هزینه OAuth 2.0 » را در زیر ببینید.
• نشانه دسترسی: یک رشته طولانی از کاراکترها که به عنوان یک اعتبار برای دسترسی به منابع محافظت شده استفاده می شود. همچنین " یک نشانه دسترسی چیست؟ " را در زیر ببینید.
• منبع محافظت شده: داده های متعلق به مالک منبع. به عنوان مثال، لیست تماس کاربر، اطلاعات حساب یا سایر داده های حساس.

جایی که Apigee Edge در آن جای می گیرد

شما می توانید از هر API پروکسی شده از طریق Apigee Edge با OAuth 2.0 محافظت کنید. Edge شامل اجرای سرور مجوز است و به این ترتیب، می تواند توکن های دسترسی را تولید و تأیید کند. توسعه دهندگان با ثبت برنامه های خود در Apigee Edge شروع می کنند. برنامه‌های ثبت‌شده می‌توانند از طریق هر یک از چهار تعامل نوع کمک هزینه ، توکن‌های دسترسی را درخواست کنند.

Apigee یک خط مشی چند وجهی OAuthV2 را ارائه می دهد که جزئیات هر نوع کمک مالی را اجرا می کند و راه اندازی OAuth را در Apigee Edge نسبتاً آسان می کند. به عنوان مثال، می‌توانید خط‌مشی را پیکربندی کنید که درخواستی برای یک نشانه دسترسی دریافت کند، تمام اعتبارنامه‌های مورد نیاز را ارزیابی کند، و اگر اعتبارنامه‌ها معتبر هستند، یک نشانه دسترسی را برمی‌گرداند.

توجه داشته باشید که هر سرور منبعی که پروکسی API ایمن شما با آنها تماس می گیرد باید پشت فایروال باشد (یعنی منابع نباید از طریق هیچ وسیله ای غیر از پروکسی API یا API دیگری که به خوبی ایمن است قابل دسترسی باشند).

انواع کمک هزینه OAuth 2.0 چیست؟

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

Apigee Edge از چهار نوع کمک مالی اصلی OAuth 2.0 پشتیبانی می کند:

• کد مجوز -- ایمن ترین نوع کمک مالی در نظر گرفته می شود. قبل از اینکه سرور مجوز یک نشانه دسترسی صادر کند، برنامه ابتدا باید یک کد مجوز را از سرور منبع دریافت کند. هر زمان که برنامه شما مرورگری را به صفحه ورود سرور منبع باز می کند و از شما دعوت می کند تا به حساب واقعی خود وارد شوید (مثلاً فیس بوک یا توییتر) این جریان را مشاهده کرده اید.

اگر با موفقیت وارد سیستم شوید، برنامه یک کد مجوز دریافت می‌کند که می‌تواند از آن برای مذاکره در مورد رمز دسترسی با سرور مجوز استفاده کند. به طور معمول، این نوع کمک هزینه زمانی استفاده می شود که برنامه به جای روی کلاینت، روی یک سرور قرار دارد. این نوع کمک هزینه بسیار ایمن در نظر گرفته می شود زیرا برنامه مشتری هرگز نام کاربری یا رمز عبور کاربر را برای سرور منبع کنترل نمی کند یا نمی بیند (یعنی، برای مثال، برنامه هرگز اعتبار توییتر شما را نمی بیند یا مدیریت نمی کند). این جریان نوع کمک هزینه OAuth "سه پا" نیز نامیده می شود.

• ضمنی -- نسخه ساده شده کد مجوز در نظر گرفته شده است. معمولاً این نوع کمک هزینه زمانی استفاده می‌شود که برنامه در مشتری باشد. برای مثال، کد برنامه در یک مرورگر با استفاده از جاوا اسکریپت یا زبان برنامه نویسی دیگر (به جای اینکه در یک وب سرور جداگانه قرار گرفته و اجرا شود) پیاده سازی می شود. در این جریان نوع اعطا، سرور مجوز به جای اینکه ابتدا یک کد مجوز صادر کند، رمز دسترسی را مستقیماً زمانی که کاربر احراز هویت شد، برمی‌گرداند. کمک های مالی ضمنی می تواند پاسخگویی برنامه را در برخی موارد بهبود بخشد، اما این مزیت باید در برابر پیامدهای امنیتی احتمالی همانطور که در مشخصات IETF توضیح داده شده است سنجیده شود.
• اعتبار رمز عبور مالک منبع -- در این جریان، زمانی که نام کاربری/رمز عبور کاربر توسط سرور مجوز تایید شود، به مشتری یک نشانه دسترسی صادر می شود. این جریان برای برنامه های کاربردی بسیار قابل اعتماد توصیه می شود. مزیت این جریان نسبت به احراز هویت اولیه این است که کاربر فقط یک بار نام کاربری/رمز عبور خود را ارائه می کند. از آن به بعد، رمز دسترسی استفاده می شود.
• اعتبار مشتری -- برای موقعیت هایی استفاده کنید که برنامه مشتری از طرف خودش عمل می کند. یعنی مشتری مالک منبع نیز هست. برای مثال، این نوع کمک هزینه معمولاً زمانی استفاده می‌شود که برنامه نیاز به دسترسی به یک سرویس ذخیره‌سازی داده پشتیبان داشته باشد. برنامه برای انجام کار خود باید از سرویس استفاده کند و در غیر این صورت سرویس برای کاربر نهایی غیرشفاف است. با این نوع کمک هزینه، یک برنامه می‌تواند با ارائه شناسه مشتری و کلیدهای مخفی مشتری به سرور مجوز، یک نشانه دسترسی دریافت کند. هیچ اقدام دیگری لازم نیست. Edge یک راه حل اعتبار مشتری خارج از جعبه را ارائه می دهد که اجرای آن برای هر پروکسی API آسان است.

توکن دسترسی چیست؟

نشانه دسترسی یک رشته طولانی از کاراکترها است که به عنوان یک اعتبار برای دسترسی به منابع محافظت شده استفاده می شود. نشانه‌های منابع (که توکن‌های حامل نیز نامیده می‌شوند) در سرصفحه‌های مجوز ارسال می‌شوند، مانند:

$ curl -H "Authorization: Bearer UAj2yiGAcMZGxfN2DhcUbl9v8WsR" \
  http://myorg-test.apigee.net/v0/weather/forecastrss?w=12797282

سرور منبع می‌داند که رمز دسترسی برای اعتبارنامه‌هایی مانند نام کاربری و رمز عبور «در داخل» قرار دارد. علاوه بر این، نشانه های دسترسی را می توان با محدودیت هایی صادر کرد، به طوری که، برای مثال، برنامه می تواند داده ها را در سرور منبع بخواند، اما ننویسد یا حذف کند. توجه داشته باشید که برای مثال، اگر برنامه در معرض خطر باشد، یک نشانه دسترسی را می توان باطل کرد. در این صورت، برای ادامه استفاده از برنامه، باید یک نشانه دسترسی جدید دریافت کنید. با این حال، شما مجبور نخواهید بود نام کاربری یا رمز عبور خود را در سرور منابع محافظت شده (به عنوان مثال، فیس بوک یا توییتر) تغییر دهید.

توکن های دسترسی عموماً دارای انقضا هستند (به دلایل امنیتی). برخی از انواع اعطا به سرور مجوز اجازه می‌دهند تا یک نشانه تازه‌سازی صادر کند، که به برنامه اجازه می‌دهد تا رمز دسترسی جدید را پس از انقضای نماد قدیمی دریافت کند. برای جزئیات بیشتر در مورد توکن های دسترسی و به روز رسانی، به مشخصات IETF OAuth 2.0 مراجعه کنید.

دسترسی محدود از طریق محدوده

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

ثبت اپلیکیشن

همه مشتریان (برنامه‌ها) باید در سرور مجوز OAuth 2.0 ثبت نام کنند که قصد دارند از آن توکن‌های دسترسی درخواست کنند. هنگامی که یک برنامه را ثبت می کنید، مجموعه ای از کلیدها را دریافت می کنید. یکی یک کلید عمومی به نام شناسه مشتری و دیگری یک کلید مخفی به نام رمز مشتری است. بدون این کلیدها، برنامه نمی تواند درخواست کدهای مجوز یا نشانه های دسترسی به سرور مجوز را صادر کند. توجه داشته باشید که در حالی که مشخصات IETF OAuth این کلیدها را شناسه مشتری و راز مشتری می نامد، رابط کاربری Apigee Edge آنها را Consumer ID و Consumer Secret می نامد. معادل هستند.

خلاصه موارد استفاده OAuth 2.0

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

امنیت کلید OAuth 2.0 در مقابل API

اعتبار سنجی کلید API به یک برنامه برای ارسال کلید به Edge نیاز دارد. کلید باید یک کلید مصرف کننده معتبر از یک برنامه توسعه دهنده Apigee Edge باشد که با پراکسی API مرتبط است. اگر به دلایلی نیاز به لغو مجوز برنامه مشتری برای برقراری تماس با یک پروکسی دارید، باید آن کلید مصرف کننده را لغو کنید. هر برنامه مشتری که از آن کلید استفاده می کند نیز نمی تواند به پروکسی API دسترسی پیدا کند. از سوی دیگر، یک توکن OAuth را می توان در هر زمانی بدون لغو کلیدهای برنامه باطل کرد. این برنامه به سادگی می تواند یک توکن جدید از طرف کاربر درخواست کند و در صورت اعطای رمز، برنامه می تواند به استفاده از پروکسی API ادامه دهد.

تفاوت دیگر بین کلید API و توکن این است که یک توکن می‌تواند شامل ویژگی‌های ابرداده باشد که می‌توانید بعداً بازیابی و استفاده کنید. به عنوان مثال، ممکن است شناسه کاربری که تماس API را انجام می دهد را ذخیره کنید و از آن برای سفارشی کردن تماس ها با سرویس هدف باطن استفاده کنید.

برای جزئیات در مورد اعتبارسنجی کلید API، به کلیدهای API مراجعه کنید. برای اطلاعات در مورد استفاده از ویژگی‌های سفارشی با نشانه‌های OAuth، به سفارشی‌سازی رمزها و کدهای مجوز مراجعه کنید.

منابع پیشنهادی

خواندن

به اطلاعات مربوط به OAuth 2.0 مراجعه کنید.