YouTube ショート動画の視聴回数のカウント方法に合わせて、Data API を更新します。
詳細
ClientLogin から OAuth 2.0 に移行する
コレクションでコンテンツを整理
必要に応じて、コンテンツの保存と分類を行います。
Ikai Lan、YouTube Developer Relations – June 2013
YouTube API は OAuth 2.0 を使用してユーザー リクエストを承認します。YouTube API で今後、ClientLogin 認証や同様の認証のサポートが追加されるかどうかという質問がよく寄せられます。ただし、ClientLogin は 2012 年 4 月 20 日に正式に非推奨となりました。このようなメカニズムを追加する予定はありません。
OAuth 2.0 認可のさまざまなフローをサポートすることが ClientLogin よりも YouTube ユーザーにとって優れている理由は多数あります。これらのフローでは、デスクトップ アプリケーション、ウェブ専用アプリケーション、ネイティブ モバイル アプリケーションのユースケースをサポートしています。また、テレビなどの高度な入力メカニズムを持たないデバイスで実行されるアプリケーションもサポートしています。これは ClientLogin では難しいことです。また、ClientLogin は多くのデベロッパーにとってリリース後に問題を引き起こすことがわかりました。その一部については、ブログ投稿の ClientLogin #FAIL で説明しています。
サーバーサイド、スタンドアロン スクリプトでの OAuth 2.0 の使用
多くのデベロッパーは、ClientLogin を使用して、ブラウザのないサーバーで実行されるコマンドライン スクリプトを承認しています。OAuth 2.0 では、ほとんどの場合ブラウザが関与します。例外は、Google Play Services を使用して GoogleAuthUtil. 経由でトークンを取得する Android アプリの場合です。
ウェブ専用フローでは、ユーザーに代わって認証済みの API 呼び出しを行うウェブサイトは、アプリケーションがアクセスしようとしている内容を説明する google.com 認証ページにユーザーをリダイレクトする必要があります。次に、ウェブ アプリケーションは API 呼び出しを作成するために使用するトークンを受け取ります。ユーザーは、connected apps and sites ページを使用して、いつでもアプリのアクセス権を取り消すことができます。
Python コードサンプルでは、コマンドライン スクリプトを使用してブラウザを起動し、ターミナル ウィンドウから API 呼び出しを行う方法、認証リダイレクト後にコードをリッスンするローカル サーバーを作成する方法、今後の API 呼び出し用にトークンを自動的に保存する方法を示しています。以下は、その実践についての動画です:
使用されているトークンは ASCII 文字列です。offline トークンの場合は、ポータブルです。このコードが同じクライアント ID とクライアント シークレットを持つ OAuth 2.0 クライアントをインスタンス化するのであれば、取得されたトークンを使用してデスクトップでスクリプトを実行し、GUI を使用せずにコードをリモート サーバー上にコピーして使用することができます。Python 以外にも、他のプログラミング言語用の Google API クライアント ライブラリには、トークンを管理するためのヘルパー メソッドも用意されています。これらのトークンはクライアント間で共有でき、下位レベルの HTTP ライブラリで直接使用することもできます（クライアント ヘッダー内または URL パラメータとして）。
以下は offline トークンを使用したサーバーサイド スクリプトの例です:
- ディレクトリの新しい動画を監視して YouTube に自動でアップロードするデーモン
- 新しい動画を使用して再生リストのコンテンツを毎日更新する cron ジョブ
- YouTube Analytics API を通じて動画データを監視し、合計再生時間が制限値を超えた場合などの特定のイベントが発生したときにチャンネル管理者に通知するスクリプト。この場合、Analytics API では ClientLogin がサポートされていないので、サポートされる認証方法は OAuth 2.0 のみである点に注意してください。
サーバー サイド プロセスに使用できる offline トークンの生成方法については、長期間有効なアクセス トークンのセクションで詳しく説明します。
クライアント ID とクライアント シークレットのベスト プラクティス
同じクライアント ID とクライアント シークレットのペアを使用するすべてのコードは、同じアクセス トークンを使用できます。クライアント ID とクライアント シークレットへのアクセスを、組織内のマシンおよび端末上で実行されるコードに限定するのが理想的です。
クライアント ID とクライアント シークレットをネイティブ モバイル アプリケーションのコードに含めないでください。携帯端末からの OAuth 2.0 認証を行っているすべてのデベロッパーはインストール済みアプリケーションのクライアント ID を使用する必要があります。これによって自分のチームがリリースしたアプリケーションからしかリクエストが送られていないことを検証するための追加情報を要求します。
Android 端末の場合は、クライント ID とクライアント シークレットを使用する代わりにパッケージ名と署名証明書のハッシュを組み合わせて使用し、アプリケーションを識別します。iOS 端末の場合は Bundle ID と App Store ID が使用されます。この情報を取得する方法については、Google API Console ヘルプページをご覧ください。
YouTube API でサービス アカウントが機能しない
サービス アカウントは YouTube Data API 呼び出しには使用できません。サービス アカウントには関連付けられた YouTube チャンネルが必要であり、新規または既存のチャンネルをサービス アカウントに関連付けることはできません。サービス アカウントを使用して YouTube Data API を呼び出すと、API サーバーはエラータイプが unauthorized、理由が youtubeSignupRequired のエラーを返します。
YouTube API に対するオフライン/長期間有効なアクセス
OAuth 2.0 では短期間有効なトークンと長期間有効なトークンを使用します。1 回限りの操作には短期間有効なアクセス トークンが適しています。このトークンは付与されてから短期間で期限切れとなります。長時間実行されるジョブの場合は、短期のアクセス トークンの取得に使用される更新トークンの取得を検討してください。
アプリが有効期間の短いアクセス トークンではなく、有効期間の長い更新トークンを受け取るようにするには、クライアント ID を作成するときに [インストール済みアプリ] フローを使用し、[インストール済みアプリの種類] の値に Other を選択します。
このユース ケースでは [Installed application] フローの使用をおすすめします。ウェブ アプリケーションで YouTube API への長期間有効なアクセスが必要な場合は、最初の認可リクエストまたはクライアント構成で access_type パラメータを offline に、approval_prompt パラメータを force に設定して取得できます。一部のクライアント ライブラリはアクセス トークンの取得とリフレッシュを管理できます。独自のカスタム認可コードを記述する場合は、コードのベースとして使用できるGoogle Code ブログの投稿をご覧ください。
携帯電話やタブレットなどの端末での OAuth 2.0 の使用
Android アプリを作成する場合、開発者は Google Play services を利用して認可の詳細を処理できます。Google Play 開発者サービスには、YouTube プラットフォームの API を含む すべての Google API の標準承認フローが用意されています。このアプローチでは、ClientLogin を使用したカスタム認証よりも、Android アプリのユーザーに優れたユーザー エクスペリエンスを提供できます。
iOS 端末の場合は、次の 2 つのオプションがあります。
「セカンド ディスプレイ」としての使用を意図した端末や簡単な入力メカニズムを持たないテレビなどの端末には OAuth 2.0 for Devices が適しています。OAuth 2.0 for Devices は、認証リクエストが要求されたときにユーザーにユニーク コードを提供します。この時点で、ユーザーは別のデバイス（ノートパソコンやスマートフォンなど）で http://google.com/device にアクセスし、一意のコードを入力するよう求められます。アプリケーションでは、次のような画面が表示されます。
ユーザーが別の端末からコードを入力している間、アプリケーションは定期的にポーリングしてコードの入力を確認します。コードが入力されると、アプリケーションは API 呼び出しを作成するためのトークンを取得します。この動作はデモでご覧いただけます。これは、ウェブを使用可能なすべての端末で実行できます。API 自体はプラットフォーム非依存なので、ウェブ表示機能を持たない端末にも有効です。デモのPython のサンプルコードを参照として掲載しています。
概要
OAuth 2.0 認証は YouTube での認証が必要なデベロッパーに柔軟性を提供します。ClientLogin に精通しているデベロッパーは、OAuth 2.0 を使用するようにアプリケーションを設定するには、最初に少し手間がかかることを認識しているかもしれません。しかし、一度移植すると、OAuth 2.0 アプリケーションは、エンドユーザーに対して複数のプラットフォームでより高い柔軟性、セキュリティ、ユーザビリティを提供します。
OAuth 2.0 やこの記事の例についてご不明な点がございましたら、StackOverflow で youtube-api タグを使用してお問い合わせください。
特に記載のない限り、このページのコンテンツはクリエイティブ・コモンズの表示 4.0 ライセンスにより使用許諾されます。コードサンプルは Apache 2.0 ライセンスにより使用許諾されます。詳しくは、Google Developers サイトのポリシーをご覧ください。Java は Oracle および関連会社の登録商標です。
最終更新日 2025-02-06 UTC。
[null,null,["最終更新日 2025-02-06 UTC。"],[[["\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)."]]
