ما در حال به‌روزرسانی Data API هستیم تا با نحوه شمارش بازدیدهای YouTube برای Shorts مطابقت داشته باشد.
بیشتر بدانید
از ClientLogin به OAuth 2.0 حرکت کنید
با مجموعه‌ها، منظم بمانید
ذخیره و طبقه‌بندی محتوا براساس اولویت‌های شما.
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، گوگل دو گزینه را ارائه می دهد:
برای دستگاه‌هایی که قرار است به‌عنوان دستگاه‌های «صفحه دوم» یا دستگاه‌هایی مانند تلویزیون‌ها بدون مکانیسم ورودی آسان عمل کنند، 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 سؤال کنید.
جز در مواردی که غیر از این ذکر شده باشد،محتوای این صفحه تحت مجوز Creative Commons Attribution 4.0 License است. نمونه کدها نیز دارای مجوز Apache 2.0 License است. برای اطلاع از جزئیات، به خطمشیهای سایت Google Developers مراجعه کنید. جاوا علامت تجاری ثبتشده Oracle و/یا شرکتهای وابسته به آن است.
تاریخ آخرین به‌روزرسانی 2025-02-06 بهوقت ساعت هماهنگ جهانی.
[null,null,["تاریخ آخرین به‌روزرسانی 2025-02-06 بهوقت ساعت هماهنگ جهانی."],[[["\u003cp\u003eYouTube APIs use OAuth 2.0 for user request authorization, and ClientLogin has been officially deprecated with no plans for future support.\u003c/p\u003e\n"],["\u003cp\u003eOAuth 2.0 offers broader support for various application types, including desktop, web, mobile, and devices with limited input capabilities, providing superior flexibility compared to ClientLogin.\u003c/p\u003e\n"],["\u003cp\u003eServer-side scripts can leverage OAuth 2.0 through offline tokens, allowing for portability and persistent access across different environments without a constant need for browser interaction.\u003c/p\u003e\n"],["\u003cp\u003eFor mobile applications, it is crucial to avoid including client ID and secret in native code, instead using mechanisms like package names and certificate hashes for Android, or bundle and app store IDs for iOS.\u003c/p\u003e\n"],["\u003cp\u003eService accounts will not work with YouTube APIs and will return an error as they cannot be connected to YouTube channels.\u003c/p\u003e\n"]]],["YouTube APIs use OAuth 2.0 for authorization, having deprecated ClientLogin. OAuth 2.0 supports various application types, including server-side scripts, web apps, and mobile apps. Server-side scripts use \"offline\" tokens for long-lived access, enabling tasks like automated video uploads and playlist updates. Client ID and secrets should be restricted to internal code. Mobile apps use unique identifiers, while \"second screen\" devices use a code-based authorization. OAuth 2.0 offers superior security and flexibility across platforms.\n"],null,["# Move from ClientLogin to OAuth 2.0\n\n*Ikai Lan, YouTube Developer Relations -- June 2013*\nYouTube APIs use [OAuth 2.0](https://developers.google.com/youtube/v3/guides/authentication) to authorize user requests. We are frequently asked whether we will add support for ClientLogin authentication or something similar in YouTube APIs going forward. However, we [officially deprecated ClientLogin as of April 20, 2012](https://developers.google.com/youtube/2.0/developers_guide_protocol_clientlogin), and there are no plans to add such a mechanism.\n\nThere are numerous reasons why we believe supporting various flows of OAuth 2.0 authorization is better for YouTube users than ClientLogin. These flows support use cases for desktop applications, web-only applications, native mobile applications, and even applications that run on devices like televisions that don't have sophisticated input mechanisms, something which is difficult to do using ClientLogin. Also, we've found that ClientLogin causes more headaches post-launch for many developers, some of which we describe in our blog post, [ClientLogin #FAIL](http://apiblog.youtube.com/2011/03/clientlogin-fail.html).\n\nUsing OAuth 2.0 for server-side, standalone scripts\n---------------------------------------------------\n\nMany developers use ClientLogin to authorize command-line scripts that run on servers without a browser. With OAuth 2.0, there's almost always going to be a browser involved -- the exception being when you're working on an Android application that uses Google Play Services to fetch tokens via [GoogleAuthUtil.](http://developer.android.com/reference/com/google/android/gms/auth/GoogleAuthUtil.html)\n\nIn a [web-only flow](https://developers.google.com/accounts/docs/OAuth2WebServer), a website that wants to make authenticated API calls on behalf of a user must redirect the user to a google.com authentication page that explains what the application is trying to access. The web application then receives a token, which it uses to make API calls. The user can then revoke the application's access at any time using the [connected apps and sites](https://accounts.google.com/IssuedAuthSubTokens) page.\n\nOur [Python code samples](https://developers.google.com/youtube/v3/code_samples/python) demonstrate how command-line scripts can launch a browser and make API calls from a terminal window, create a local server to listen for the code after the authorization redirect, and automatically save a token for future API calls. A video of this in action is below:\n\nThe token used is an ASCII string. If it is an `offline` token, it is *portable* . Using the retrieved token, you will be able to run the script on your desktop, then copy and use the code on a remote server without a GUI, provided that code instantiates an OAuth 2.0 client with the same client ID and secret. In addition to Python, the [Google API client libraries](https://developers.google.com/discovery/libraries) for other programming languages also provide helper methods for managing tokens, which can be shared between clients and even used in lower-level HTTP libraries directly [in a client header or as a URL parameter](https://developers.google.com/accounts/docs/OAuth2UserAgent#callinganapi).\n\nSome examples of server-side scripts that use offline tokens:\n\n- A daemon that monitors a directory for new videos to automatically upload to YouTube\n- A cron job that that updates playlists daily with new content\n- A script that monitors video data via the [YouTube Analytics API](https://developers.google.com/youtube/analytics/) and notifies channel managers when certain events take place, such as aggregate watch time exceeding a limit. Note that in this case, OAuth 2.0 is the only supported authorization method because the Analytics API does not support ClientLogin.\n\nThe section on [long-lived access tokens](#offline_access) provides more detail about how to generate the offline tokens that can be used for server side processes.\n\nClient ID and client secret best practices\n------------------------------------------\n\nAny code that shares the same client ID and secret pair can use the same access tokens. It's best to restrict access to client ID and client secrets to code that runs on machines and devices within your organization.\n\nDo not include your client ID and client secret as part of your native mobile applications code. All developers doing OAuth 2.0 authentication from a mobile device should make use of the \"Installed application\" client ID, which asks for additional information to verify that the request is coming only from an application released by your team.\n\nOn Android devices, instead of using a client ID and client secret, your application is identified using a combination of the package name and a signing certificate hash. On iOS devices, the bundle ID and the app store ID are used. The official documentation on retrieving this information can be found on the [Google API Console help page](https://developers.google.com/console/help/#installed_applications).\n\nService Accounts do not work with the YouTube API\n-------------------------------------------------\n\nService accounts do not work for YouTube Data API calls because service accounts require an associated YouTube channel, and you cannot associate new or existing channels with service accounts. If you use a service account to call the YouTube Data API, the API server [returns an error](https://developers.google.com/youtube/v3/docs/errors#youtube.api.RequestContextError-unauthorized-youtubeSignupRequired) with the error type set to `unauthorized` and the reason set to `youtubeSignupRequired`.\n\nOffline/long-lived access to the YouTube API\n--------------------------------------------\n\nOAuth 2.0 has short-lived tokens and long-lived tokens. For one-off operations, short-lived [access tokens](https://tools.ietf.org/html/rfc6749#section-1.4) are the best option. These tokens expire shortly after they are granted. For long running jobs, you may want to look into acquiring a [refresh token](https://developers.google.com/youtube/v3/guides/authentication#OAuth2_Refreshing_a_Token), which is used to fetch short-lived access tokens.\n\nTo ensure that your application receives a long-lived refresh token and not a short-lived access token, use the \"Installed Application\" flow when creating a client ID, and select `Other` for the \"Installed application type\" value:\n\nIt's recommended that you use the \"Installed application\" flow for this use case. If you need long-lived access to the YouTube API in a web application, you can retrieve one by setting the `access_type` parameter to `offline` and the `approval_prompt` parameter to `force` in the [initial authorization request or your client configuration](https://developers.google.com/accounts/docs/OAuth2WebServer#offline). Some client libraries will manage fetching and refreshing access tokens. If you are interested in writing your own custom authorization code, we published a [blog post on the Google Code blog](http://googlecode.blogspot.com/2011/10/upcoming-changes-to-oauth-20-endpoint.html) that you can use as the basis for your code.\n\nUsing OAuth 2.0 with phones, tablets and other devices\n------------------------------------------------------\n\nWhen writing Android applications, developers can take advantage of [Google Play services](http://developer.android.com/google/play-services/index.html) to handle the authorization details. Google Play services offers a [standard authorization flow for all Google APIs](http://developer.android.com/google/play-services/auth.html), including APIs for the YouTube platform. This approach will provide a far superior user experience for users of your Android application than a custom authentication using ClientLogin.\n\nOn iOS devices, Google provides two options:\n\n\n- the [Google+ Platform for iOS](https://developers.google.com/+/mobile/ios/), which integrates sign-in for Google products and also enables social features\n- the [gtm-oauth2 toolkit](https://github.com/google/gtm-oauth2), which provides an authorization UIWebView and manages tokens\n\n\u003cbr /\u003e\n\nFor devices that are meant to act as \"second screen\" devices or devices such as televisions without easy-to-use input mechanisms, [OAuth 2.0 for Devices](https://developers.google.com/accounts/docs/OAuth2ForDevices) is the preferred approach. OAuth 2.0 for Devices works by presenting a unique code for a user when an authorization request is required. At this point, users are asked to browse to \u003chttp://google.com/device\u003e on another device, such as a laptop or a phone, and enter in the unique code. The application presents a screen that looks something like this:\n\nWhile the user is entering the code on another device, the application periodically polls to see if the code has been entered. Once it has, it retrieves a token for making API calls. To see this in action, check out [the demo](http://stb-web-app.appspot.com/static/index.html), which can be run on any web-enabled device. The API itself is platform-agnostic, making it useful for devices that don't have web rendering capabilities. We've posted [sample code in Python](https://code.google.com/p/gdata-samples/source/browse/trunk/ytplayer/stb-web-app/?r=238) for the demo to be used as a reference.\n\nSummary\n-------\n\nOAuth 2.0 authorization provides flexibility for developers that require YouTube authorization. Developers familiar with ClientLogin may find that setting up their applications to use OAuth 2.0 requires slightly more work to get started, but once ported, OAuth 2.0 applications offer more flexibility, security and usability across multiple platforms for end users.\n\nIf you have any more questions about OAuth 2.0 or any of the examples in this article, please feel feel to ask with the [youtube-api tag on StackOverflow](http://stackoverflow.com/questions/tagged/youtube-api)."]]
