Ikai Lan، YouTube Developer Relations – June 2013
APIهای YouTube از OAuth 2.0 برای تأیید درخواست‌های کاربر استفاده می‌کنند. اغلب از ما می‌پرسند که آیا در آینده پشتیبانی برای احراز هویت ClientLogin یا چیزی مشابه در APIهای YouTube اضافه خواهیم کرد. با این حال، ما به طور رسمی ClientLogin از 20 آوریل 2012 منسوخ کردیم و هیچ برنامه ای برای اضافه کردن چنین مکانیزمی وجود ندارد.
دلایل متعددی وجود دارد که چرا ما معتقدیم پشتیبانی از جریان‌های مختلف مجوز OAuth 2.0 برای کاربران YouTube بهتر از ClientLogin است. این جریان‌ها از موارد استفاده برای برنامه‌های دسکتاپ، برنامه‌های فقط تحت وب، برنامه‌های موبایل بومی، و حتی برنامه‌هایی که روی دستگاه‌هایی مانند تلویزیون‌هایی که مکانیسم‌های ورودی پیچیده‌ای ندارند، اجرا می‌شوند، پشتیبانی می‌کنند، کاری که انجام آن با استفاده از ClientLogin دشوار است. همچنین، متوجه شده‌ایم که ClientLogin پس از راه‌اندازی باعث سردردهای بیشتری برای بسیاری از توسعه‌دهندگان می‌شود، که برخی از آنها را در پست وبلاگ خود، ClientLogin #FAIL توضیح می‌دهیم.
استفاده از OAuth 2.0 برای اسکریپت های مستقل سمت سرور
بسیاری از توسعه دهندگان از ClientLogin برای مجوز دادن به اسکریپت های خط فرمان که بر روی سرورهای بدون مرورگر اجرا می شوند، استفاده می کنند. با OAuth 2.0، تقریباً همیشه یک مرورگر درگیر است - به استثنای زمانی که روی یک برنامه اندروید کار می کنید که Google Play Services برای واکشی نشانه ها از طریق GoogleAuthUtil.
در یک جریان فقط وب ، وب‌سایتی که می‌خواهد از طرف یک کاربر تماس‌های API احراز هویت شده برقرار کند، باید کاربر را به یک صفحه تأیید هویت google.com هدایت کند که توضیح می‌دهد برنامه به چه چیزی می‌خواهد دسترسی داشته باشد. سپس برنامه وب یک توکن دریافت می کند که از آن برای برقراری تماس های API استفاده می کند. سپس کاربر می تواند در هر زمان با استفاده از صفحه connected apps and sites دسترسی برنامه را لغو کند.
نمونه‌های کد پایتون ما نشان می‌دهد که چگونه اسکریپت‌های خط فرمان می‌توانند یک مرورگر را راه‌اندازی کنند و از یک پنجره ترمینال تماس‌های API ایجاد کنند، یک سرور محلی برای گوش دادن به کد پس از تغییر مسیر مجوز ایجاد کنند، و به‌طور خودکار یک توکن را برای تماس‌های API آینده ذخیره کنند. ویدئویی از این عمل در زیر آمده است:
توکن مورد استفاده یک رشته ASCII است. اگر توکن offline باشد، قابل حمل است. با استفاده از رمز بازیابی شده، می‌توانید اسکریپت را روی دسکتاپ خود اجرا کنید، سپس کد را روی یک سرور راه دور بدون رابط کاربری گرافیکی کپی و استفاده کنید، مشروط بر اینکه کد یک کلاینت OAuth 2.0 را با همان شناسه مشتری و مخفی ارائه کند. علاوه بر پایتون، کتابخانه‌های سرویس گیرنده Google API برای سایر زبان‌های برنامه‌نویسی نیز روش‌های کمکی را برای مدیریت نشانه‌ها ارائه می‌کنند که می‌توانند بین کلاینت‌ها به اشتراک گذاشته شوند و حتی در کتابخانه‌های HTTP سطح پایین‌تر به‌طور مستقیم در سرآیند کلاینت یا به‌عنوان پارامتر URL استفاده شوند.
چند نمونه از اسکریپت های سمت سرور که از نشانه های آفلاین استفاده می کنند:
- دیمونی که فهرستی را برای آپلود خودکار ویدیوهای جدید در یوتیوب کنترل می کند
- یک کار جدید که لیست های پخش را روزانه با محتوای جدید به روز می کند
- اسکریپتی که داده‌های ویدیویی را از طریق YouTube Analytics API نظارت می‌کند و مدیران کانال را در صورت وقوع رویدادهای خاص، مانند زمان مجموع تماشای بیش از حد مجاز، مطلع می‌کند. توجه داشته باشید که در این مورد، OAuth 2.0 تنها روش مجوز پشتیبانی است زیرا API Analytics از ClientLogin پشتیبانی نمی کند.
بخش مربوط به توکن های دسترسی طولانی مدت جزئیات بیشتری در مورد نحوه تولید توکن های آفلاین ارائه می دهد که می توانند برای فرآیندهای سمت سرور استفاده شوند.
شناسه مشتری و بهترین شیوه های راز مشتری
هر کدی که شناسه مشتری و جفت مخفی یکسانی را به اشتراک بگذارد، می‌تواند از نشانه‌های دسترسی یکسانی استفاده کند. بهتر است دسترسی به شناسه مشتری و اسرار مشتری را به کدهایی محدود کنید که روی ماشین‌ها و دستگاه‌های درون سازمان شما اجرا می‌شوند.
شناسه مشتری و راز سرویس گیرنده خود را به عنوان بخشی از کد برنامه های کاربردی تلفن همراه خود وارد نکنید. همه برنامه‌نویس‌هایی که احراز هویت OAuth 2.0 را از دستگاه تلفن همراه انجام می‌دهند باید از شناسه کلاینت «برنامه نصب‌شده» استفاده کنند، که اطلاعات بیشتری را برای تأیید اینکه درخواست فقط از برنامه‌ای که توسط تیم شما منتشر شده است، درخواست می‌کند.
در دستگاه‌های اندرویدی، به جای استفاده از شناسه مشتری و راز سرویس گیرنده، برنامه شما با استفاده از ترکیبی از نام بسته و هش گواهی امضا شناسایی می‌شود. در دستگاه‌های iOS، شناسه بسته و شناسه فروشگاه برنامه استفاده می‌شود. اسناد رسمی در مورد بازیابی این اطلاعات را می توان در صفحه راهنمای Google API Console پیدا کرد.
حساب‌های سرویس با API YouTube کار نمی‌کنند
حساب‌های سرویس برای تماس‌های YouTube Data API کار نمی‌کنند زیرا حساب‌های سرویس به یک کانال YouTube مرتبط نیاز دارند و نمی‌توانید کانال‌های جدید یا موجود را با حساب‌های سرویس مرتبط کنید. اگر از یک حساب سرویس برای فراخوانی YouTube Data API استفاده می‌کنید، سرور API خطایی با نوع خطا روی unauthorized و دلیل تنظیم شده روی youtubeSignupRequired برمی‌گرداند.
دسترسی آفلاین/ طولانی مدت به YouTube API
OAuth 2.0 دارای توکن های کوتاه مدت و توکن های طولانی مدت است. برای عملیات یکباره، توکن های دسترسی کوتاه مدت بهترین گزینه هستند. این توکن‌ها مدت کوتاهی پس از اعطای منقضی می‌شوند. برای کارهای طولانی مدت، ممکن است بخواهید به دنبال به دست آوردن یک نشانه رفرش باشید که برای واکشی توکن های دسترسی کوتاه مدت استفاده می شود.
برای اطمینان از اینکه برنامه شما یک نشانه رفرش طولانی مدت دریافت می کند و نه یک نشانه دسترسی کوتاه مدت، از جریان "برنامه نصب شده" هنگام ایجاد شناسه مشتری استفاده کنید و برای مقدار "نوع برنامه نصب شده" Other انتخاب کنید:
توصیه می شود از جریان "برنامه نصب شده" برای این مورد استفاده کنید. اگر به دسترسی طولانی مدت به YouTube API در یک برنامه وب نیاز دارید، می‌توانید با تنظیم پارامتر access_type در offline و پارامتر approval_prompt برای force در درخواست مجوز اولیه یا پیکربندی مشتری خود ، یکی را بازیابی کنید. برخی از کتابخانه‌های سرویس گیرنده واکشی و به‌روزرسانی نشانه‌های دسترسی را مدیریت می‌کنند. اگر علاقه مند به نوشتن کد مجوز سفارشی خود هستید، ما یک پست وبلاگ در وبلاگ Google Code منتشر کردیم که می توانید از آن به عنوان مبنای کد خود استفاده کنید.
استفاده از OAuth 2.0 با تلفن، تبلت و سایر دستگاه ها
هنگام نوشتن برنامه های Android، توسعه دهندگان می توانند از Google Play services برای رسیدگی به جزئیات مجوز استفاده کنند. خدمات Google Play یک جریان مجوز استاندارد برای همه APIهای Google ، از جمله APIهای پلت فرم YouTube ارائه می دهد. این رویکرد نسبت به احراز هویت سفارشی با استفاده از ClientLogin ، تجربه کاربری بسیار برتری را برای کاربران برنامه اندروید شما فراهم می‌کند.
در دستگاه های iOS، گوگل دو گزینه را ارائه می دهد:
- Google+ Platform for iOS ، که ورود به سیستم را برای محصولات Google یکپارچه می کند و همچنین ویژگی های اجتماعی را فعال می کند
- gtm-oauth2 toolkit که مجوز UIWebView را ارائه می دهد و توکن ها را مدیریت می کند
برای دستگاه‌هایی که قرار است به‌عنوان دستگاه‌های «صفحه دوم» یا دستگاه‌هایی مانند تلویزیون‌ها بدون مکانیسم ورودی آسان عمل کنند، OAuth 2.0 for Devices رویکرد ترجیحی است. OAuth 2.0 for Devices با ارائه یک کد منحصر به فرد برای کاربر در زمانی که درخواست مجوز لازم است کار می کند. در این مرحله، از کاربران خواسته می‌شود در دستگاه دیگری مانند لپ‌تاپ یا تلفن به http://google.com/device مراجعه کرده و کد منحصربه‌فرد را وارد کنند. این برنامه صفحه ای را ارائه می دهد که چیزی شبیه به این است:
در حالی که کاربر در حال وارد کردن کد در دستگاه دیگری است، برنامه به صورت دوره ای نظرسنجی می کند تا ببیند آیا کد وارد شده است یا خیر. پس از این کار، یک توکن برای برقراری تماس های API بازیابی می کند. برای مشاهده عملکرد آن، نسخه آزمایشی را بررسی کنید، که می‌تواند روی هر دستگاهی که دارای وب است اجرا شود. API به خودی خود یک پلتفرم آگنوستیک است و برای دستگاه هایی که قابلیت رندر وب را ندارند مفید است. ما نمونه کدی را در پایتون برای نسخه ی نمایشی ارسال کرده ایم تا به عنوان مرجع استفاده شود.
خلاصه
مجوز OAuth 2.0 برای توسعه دهندگانی که به مجوز YouTube نیاز دارند، انعطاف پذیری را فراهم می کند. توسعه دهندگان آشنا با ClientLogin ممکن است متوجه شوند که راه اندازی برنامه های خود برای استفاده از OAuth 2.0 به کار بیشتری برای شروع نیاز دارد، اما پس از انتقال، برنامه های OAuth 2.0 انعطاف پذیری، امنیت و قابلیت استفاده بیشتری را در چندین پلتفرم برای کاربران نهایی ارائه می دهند.
اگر سؤال بیشتری در مورد OAuth 2.0 یا هر یک از نمونه‌های این مقاله دارید، لطفاً با تگ youtube-api در StackOverflow سؤال کنید.