YouTube Engineering and Developers Blog: 六月 2013

Engineering and Developers Blog

What's happening with engineering and developers at YouTube

Google+ page identities and the YouTube API

2013年6月24日星期一

As more YouTube channels start using Google+ page identities, here are some best practices to ensure that your code can make authorized API calls to access the channel.
With Google+ page identities, there can be many channels associated with a single Google Account. For example, when a user Alice Smith signs into her Google Account, she may have her “Alice Smith” (personal) channel on that account, and potentially additional channels, linked to Google+ pages, on associated accounts. These associated accounts do not have a password by default; she gets access to them by signing into her personal account, and then using a switcher to go back and forth between them.
How does this channel selection work with APIs? With API access through web-based OAuth 2, the switcher comes automatically. The web flow will ask Alice which account she wants to use, after she signs into her “Alice Smith” account. The OAuth 2 tokens your application gets back work just as they do today.

The OAuth 2 web-based “Select an account” interface, allowing a user to grant access to their personal channel or any channels linked to Google+ pages that they manage.
If you’re not using web-based OAuth 2 (you are still relying on one of our deprecated authorization methods), or if you are an Android developer who is using OAuth 2 (there is currently no native Android account switcher), then the API will choose the “wrong” channel in some cases, or even no channel (e.g., if the personal account doesn’t have a channel). When this happens, the user has two options to specify the correct channel:

Use the Advanced Account Settings tool to select which channel should be used. This is recommended when a user has one channel they want to use for all applications.

Set up login credentials for each of their Google+ pages, and specify those credentials, not their normal Google Account credentials, for each application that needs access.

As a best practice, we recommend that you ensure users know of these options, so your application will access the correct channel. Even more importantly, we recommend that all applications provide visual feedback letting users know which channel is currently authorized. If you’re still using version 2 of the YouTube Data API, you can retrieve the profile of the special identifier default; this corresponds to the currently authorized channel’s profile. In the version 2 response, the channel’s display name is returned as an attribute of yt:username, and the profile image can be found by looking at media:thumbnail. If you’ve started using version 3, then the method to use is channels.list() with the part=snippet and mine=true parameters set. The version 3 response contains a channel’s display name in channel.snippet.title and profile image in channel.snippet.thumbnails.default.url.
To summarize, here are the high-level points to keep in mind:

OAuth 2 will automatically display a “Select an account” web interface, allowing users with multiple channels associated with their account to choose which one they’re authorizing access to.

...this doesn’t apply to Android OAuth 2, yet.

Use of other authorization methods will mean some users need to specify which channel to use, either in their Advanced Account Settings (if they consistently use one channel), or by setting up login credentials for each channel, and using them as needed.

All developers are strongly encouraged to display visual feedback letting their users know which channel is currently authorized.

Update: This YouTube Developers Live show with Sherry Listgarten, the Product Manager responsible for Google+ and YouTube integration, goes into more details about plans for Google identities and YouTube channels. It also contains a video walkthrough of many of the points covered in this blog post.

Cheers,—Jeff Posnick, YouTube API Team

Google

標籤： YouTube Engineering & Developers Blog

.net
360
acceleration
access control
accessibility
actionscript
activities
activity
android
announcements
apis
app engine
appengine
apps script
as2
as3
atom
authentication
authorization
authsub
best practices
blackops
blur faces
bootcamp
captions
categories
channels
charts
chrome
chromeless
client library
clientlibraries
clientlogin
code
color
comments
compositing
create
curation
custom player
decommission
default
deprecation
devs
direct
discovery
docs
Documentation RSS
dotnet
education
embed
embedding
events
extension
feeds
flash
format
friendactivity
friends
fun
gears
google developers live
google group
googlegamedev
googleio
html5
https
iframe
insight
io12
io2011
ios
iphone
irc
issue tracker
java
javascript
json
json-c
jsonc
knight
legacy
Live Streaming API
LiveBroadcasts API
logo
machine learning
mashups
media:keywords keywords tags metadata
metadata
mobile
mozilla
NAB 2016
news
oauth
oauth2
office hours
open source
partial
partial response
partial update
partners
patch
php
player
playlists
policy
previews
pubsubhubbub
push
python
quota
rails
releases
rendering
reports
responses
resumable
ruby
samples
sandbox
shortform
ssl https certificate staging stage
stack overflow
stage video
staging
standard feeds
storify
storyful
subscription
sup
Super Chat API
survey
tdd
theme
tos
tutorials
updates
uploads
v2
v3
video
video files
video transcoding
virtual reality
voting
VR
watch history
watchlater
webvtt
youtube
youtube api
YouTube Data API
youtube developers live
youtube direct
YouTube Engineering & Developers Blog
YouTube IFrame Player API
YouTube live
YouTube Reporting API
ytd

Feed

Google
Privacy
Terms

Engineering and Developers Blog

Google+ page identities and the YouTube API

標籤

Archive

Feed