YouTube에서 Shorts 동영상의 조회수를 집계하는 방식에 맞게 Data API를 업데이트하고 있습니다.
자세히 알아보기
ClientLogin에서 OAuth 2.0으로 이전
컬렉션을 사용해 정리하기
내 환경설정을 기준으로 콘텐츠를 저장하고 분류하세요.
이카이 란, YouTube Developer Relations – June 2013
YouTube API는 OAuth 2.0을 사용하여 사용자 요청을 승인합니다. 향후 YouTube API에 ClientLogin 인증 또는 유사한 기능을 추가할 예정인지에 대한 문의가 자주 있습니다. 하지만 2012년 4월 20일부터 ClientLogin가 공식적으로 지원 중단되었으며 이러한 메커니즘을 추가할 계획은 없습니다.
YouTube는 OAuth 2.0 승인의 다양한 흐름을 지원하는 것이 ClientLogin보다 YouTube 사용자에게 더 유리하다고 생각하는 데는 여러 가지 이유가 있습니다. 이러한 흐름은 데스크톱 애플리케이션, 웹 전용 애플리케이션, 네이티브 모바일 애플리케이션, 심지어 정교한 입력 메커니즘이 없는 TV와 같은 기기에서 실행되는 애플리케이션의 사용 사례를 지원합니다. 이는 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 클라이언트 라이브러리는 토큰을 관리하는 도우미 메서드도 제공합니다. 이 메서드는 클라이언트 간에 공유할 수 있으며 클라이언트 헤더 또는 URL 매개변수로 직접 하위 수준 HTTP 라이브러리에서도 사용할 수 있습니다.
다음은 오프라인 토큰을 사용하는 서버측 스크립트의 몇 가지 예입니다.
- YouTube에 자동으로 업로드하기 위해 새 동영상 관련 디렉토리를 모니터링하는 데몬
- 새 콘텐츠로 재생목록을 매일 업데이트하는 크론 작업
- YouTube Analytics API를 통해 동영상 데이터를 모니터링하고 집계 시청 시간이 한도를 초과하는 등 특정 이벤트가 발생하면 채널 관리자에게 알리는 스크립트입니다. 이 경우 Analytics API에서 ClientLogin을 지원하지 않기 때문에 인증 메소드로는 OAuth 2.0만 지원됩니다.
장기 액세스 토큰의 섹션에서는 서버측 처리에 사용할 수 있는 오프라인 토큰을 생성하는 방법에 대해 자세히 설명합니다.
클라이언트 ID 및 클라이언트 비밀번호 권장사항
동일한 클라이언트 ID 및 보안 비밀번호 쌍을 공유하는 모든 코드는 동일한 액세스 토큰을 사용할 수 있습니다. 조직 내 시스템 및 기기에서 실행되는 코드의 클라이언트 ID 및 클라이언트 비밀번호에 대한 액세스를 제한하는 것이 좋습니다.
네이티브 모바일 애플리케이션 코드의 일부로 클라이언트 ID와 클라이언트 비밀번호를 포함하지 마세요. 휴대기기에서 OAuth 2.0 인증을 사용하는 모든 개발자는 자신의 팀에서 출시된 애플리케이션에서만 요청이 전송됨을 확인하기 위해 추가 정보를 요청하는 '설치된 애플리케이션' 클라이언트 ID를 사용해야 합니다.
Android 기기에서는 클라이언트 ID와 클라이언트 보안 비밀번호 대신 패키지 이름과 서명 인증서 해시의 조합을 사용하여 애플리케이션이 식별됩니다. iOS 기기에서는 번들 ID와 App Store ID가 사용됩니다. 이 정보를 가져오는 방법에 관한 공식 문서는 Google API Console 도움말 페이지에서 확인할 수 있습니다.
YouTube API에서 작동하지 않는 서비스 계정
서비스 계정에는 연결된 YouTube 채널이 필요하며 새 채널이나 기존 채널을 서비스 계정과 연결할 수 없으므로 YouTube Data API 호출에는 서비스 계정이 작동하지 않습니다. 서비스 계정을 사용하여 YouTube Data API를 호출하면 API 서버는 오류 유형이 unauthorized이고 이유가 youtubeSignupRequired로 설정된 오류를 반환합니다.
YouTube API에 대한 오프라인/장기 액세스
OAuth 2.0에는 단기 토큰과 장기 토큰이 있습니다. 일회성 작업의 경우 단기 액세스 토큰이 가장 적합합니다. 이러한 토큰은 부여된 직후에 만료됩니다. 장기 실행 작업의 경우 단기 액세스 토큰을 가져오는 데 사용되는 갱신 토큰을 가져오는 것이 좋습니다.
애플리케이션이 단기 액세스 토큰이 아닌 장기 갱신 토큰을 수신하도록 하려면 클라이언트 ID를 만들 때 '설치된 애플리케이션' 흐름을 사용하고 '설치된 애플리케이션 유형' 값으로 Other를 선택합니다.
이 사용 사례에는 '설치된 애플리케이션' 흐름을 사용하는 것이 좋습니다. 웹 애플리케이션에서 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 기기의 경우 Google은 다음과 같은 2가지 옵션을 제공합니다.
'보조 화면' 기기 또는 사용하기 쉬운 입력 메커니즘이 없는 TV와 같은 기기의 경우 기기용 OAuth 2.0이 권장됩니다. 기기용 OAuth 2.0은 승인 요청이 필요할 때 사용자에게 고유한 코드를 표시하여 작동합니다. 이때 사용자에게 노트북이나 휴대전화와 같은 다른 기기에서 http://google.com/device로 이동하여 고유 코드를 입력하라는 메시지가 표시됩니다. 애플리케이션에서는 다음과 같은 화면을 표시합니다.
사용자가 다른 기기에서 코드를 입력하는 동안 애플리케이션은 주기적으로 폴링하여 코드가 입력되었는지 확인합니다. 그런 다음 API 호출을 위한 토큰을 가져옵니다. 실제로 작동하는 모습을 보려면 웹 지원 기기에서 실행할 수 있는 데모를 확인하세요. API 자체는 플랫폼과 관계가 없으므로 웹 렌더링 기능이 없는 기기에 유용합니다. 참고용으로 데모에 사용할 수 있는 Python 샘플 코드를 게시했습니다.
요약
OAuth 2.0 승인은 YouTube 승인이 필요한 개발자에게 유연성을 제공합니다. ClientLogin에 익숙한 개발자는 OAuth 2.0을 사용하도록 애플리케이션을 설정하는 데 시작하는 데 약간 더 많은 작업이 필요할 수 있지만 일단 포팅되면 OAuth 2.0 애플리케이션은 최종 사용자에게 여러 플랫폼에서 더 많은 유연성, 보안, 사용성을 제공합니다.
OAuth 2.0 또는 이 도움말의 예시와 관련하여 더 궁금한 점이 있으면 언제든지 StackOverflow에서 youtube-api 태그를 사용하여 질문해 주세요.
달리 명시되지 않는 한 이 페이지의 콘텐츠에는 Creative Commons Attribution 4.0 라이선스에 따라 라이선스가 부여되며, 코드 샘플에는 Apache 2.0 라이선스에 따라 라이선스가 부여됩니다. 자세한 내용은 Google Developers 사이트 정책을 참조하세요. 자바는 Oracle 및/또는 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)."]]
