مقدمه‌ای بر 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 را به‌خوبی نشان می‌دهد. اگر با اصطلاحات استفاده‌شده در این نمودار آشنا نیستید، این بخش را برای آشنایی سریع بخوانید.

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

• کارخواه: «برنامه» نیز نامیده می‌شود. می‌تواند برنامه‌ای باشد که روی دستگاه همراه اجرا می‌شود یا برنامه وب سنتی. برنامه ازطرف مالک منبع، برای دارایی‌های محافظت‌شده از سرور منبع درخواست می‌کند. مالک منبع باید به برنامه اجازه دهد به منابع محافظت‌شده دسترسی داشته باشد.
• مالک منبع: همچنین «کاربر نهایی» نامیده می‌شود. این شخص معمولاً فرد (یا نهاد دیگری) است که می‌تواند دسترسی به منبع محافظت‌شده را اعطا کند. برای مثال، اگر برنامه‌ای نیاز داشته باشد از داده‌های یکی از سایت‌های رسانه‌های اجتماعی شما استفاده کند، شما مالک منبع هستید -- تنها کسی که می‌تواند به برنامه اجازه دسترسی به داده‌هایتان را بدهد.
• سرور منبع: سرور منبع را به‌عنوان سرویسی مثل Facebook،‏ Google، یا X؛ یا سرویس منابع انسانی در اینترانت؛ یا سرویس شریک در اکسترانت B2B درنظر بگیرید. Apigee Edge هرگاه اعتبارسنجی کد OAuth برای پردازش درخواست‌های API لازم باشد، سرور منبع است. سرور منبع قبل‌از اینکه منابع محافظت‌شده را به برنامه ارائه دهد، به نوعی مجوز نیاز دارد.
• سرور مجوز: سرور مجوز مطابق با مشخصات 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 را نسبتاً آسان می‌کند. برای مثال، می‌توانید خط‌مشی‌ای را پیکربندی کنید که درخواست دریافت کد دسترسی را دریافت کند، همه اعتبارنامه‌های موردنیاز را ارزیابی کند، و درصورت معتبر بودن اعتبارنامه‌ها، کد دسترسی را برگرداند.

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

انواع اعطای OAuth 2.0 چیست؟

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

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

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

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

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

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

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

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

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

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

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

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

ثبت برنامه

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

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

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

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

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

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

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

منابع توصیه‌شده

خواندن

به آشنایی با OAuth 2.0 مراجعه کنید.