مقدمه ای بر 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، و چه با اجازه دادن به برنامه‌ی شخص ثالث برای دسترسی به سرویس HTTP از طرف خودش.»

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

جریان OAuth 2.0

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

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

• کلاینت: که به آن «اپلیکیشن» نیز گفته می‌شود. می‌تواند یک اپلیکیشن در حال اجرا روی دستگاه تلفن همراه یا یک اپلیکیشن وب سنتی باشد. اپلیکیشن از طرف مالک منبع، درخواست‌هایی را برای دارایی‌های محافظت‌شده به سرور منبع ارسال می‌کند. مالک منبع باید به اپلیکیشن اجازه دسترسی به منابع محافظت‌شده را بدهد.
• مالک منبع: که به آن "کاربر نهایی" نیز گفته می‌شود. این شخص (یا نهاد دیگر) معمولاً کسی است که قادر به اعطای دسترسی به یک منبع محافظت‌شده است. برای مثال، اگر یک برنامه نیاز به استفاده از داده‌های یکی از سایت‌های رسانه اجتماعی شما داشته باشد، شما مالک منبع هستید -- تنها کسی که می‌تواند به برنامه اجازه دسترسی به داده‌های شما را بدهد.
• سرور منبع: سرور منبع را می‌توان به عنوان سرویسی مانند فیس‌بوک، گوگل یا توییتر در نظر گرفت؛ یا یک سرویس منابع انسانی در اینترانت شما؛ یا یک سرویس همکار در اکسترانت 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 نسبتاً آسان می‌کند. به عنوان مثال، می‌توانید سیاستی را پیکربندی کنید که درخواستی برای یک توکن دسترسی دریافت کند، تمام اعتبارنامه‌های مورد نیاز را ارزیابی کند و در صورت معتبر بودن اعتبارنامه‌ها، یک توکن دسترسی را برگرداند.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ثبت یک برنامه

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

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

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

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

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

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

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

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

خواندن

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