Skip to main content

How To Use the Youtube Data API: Authentication

After a couple days trouble with the Youtube Data API and the provided Python wrappers around it, I thought it would be good to collect my findings on what works and doesn't and to fill in the gaps that I see in the docs. I really hope this series will be useful to some others in my position.

Some Doors Are Locked and Some Doors Are Ajar

A lot of the APIs use requires no authentication, not even a developer key. This makes a lot of the most common, read-only integrations a snap. However, I think this makes it more difficult to adjust when the need to authenticate for other integration comes along. This did some damage to my schedule, so I'm going to help others avoid the problem.

Public operations are simple. Youtube gives us resources in the form of feeds and images and other things at API locations, like to get the first thumbnail of a video. Just plug in your video ID and go.

When you get into the realm of authenticated requests, you've got to get a bit of foundation in place, to start. I don't recommend crafting any requests your self, so grab the client library for gdata. You'll also want to register your site and get a developer key.

With that all set up, is going to be your friend. The service object begins unauthenticated. At user authorization is can be upgraded single and long-term authenticated use. There is a ClientLogin path, intended for desktop applications, where you actually ask for their username and password. We won't be covering that.

AuthSub is going to be used. With this method, the user is directed from our site to a crafted URL at YouTube, essentially telling them "Hey, I want this user to let me access their account. Is that alright with them?" The user has the job of deciding if you are trusted or not. When they do, Youtube generates a special token to send to a URL you provided. The token you've been given is good for one request, so make it a good one! The best use of that one-time token is usually going to be exchanging it for a session token that you can keep using forever, until the user revokes your rights to their account. These are the steps we're going to see next.

def authsub_url(self, request):
base = '/return/path/at/my/website/'
next = 'http://%s%s?next=%s' % (
scope = ''
secure = False
session = True

return yt_service.GenerateAuthSubURL(next, scope, secure, session)

The function generates and returns a unique URL to direct our user to. It takes a request, because we need the host and I used the current URL in my own usage and the absolute URI as the return destination coming back from Youtube. You can also assume here that yt_service is an instance of, of course. Of note is the session parameter, passed as True, which enables the token we receive to be upgraded to a session token. The user will get a different message from Youtube, depending on this parameter, so they know what you might be doing and how much access they're authorizing.

You're callback URL will be brought up by the user with a token parameter added to the querystring, and you'll be expected to keep track of that.

session_token = yt_service.current_token.get_token_string()

This part tripped me up for a bit, because the way the official docs are split among the official guide, the python guide, and the actual definitive(ish) API reference, it wasn't as clear that the single-use token and the session-token were distinct tokens, rather than the original becoming a session-token, which my understand was, at first. It would be a lot more clear, I think, if that UpgradeToSessionToken() actually returned that new token. Of course, this isn't important if you're just using the yt_service right now. If you need to store that token for future use, however, then it happens to be really important information.

Later, if you saved this token, you can easily use it again:



The ease of use is pretty nice. Generate the authorization URL and direct the user there, take the returned token and upgrade it for session use, and from then on, you can do lots of fun things when their account.


Popular posts from this blog

Why I Switched From Git to Microsoft OneDrive

I made the unexpected move with a string of recent projects to drop Git to sync between my different computers in favor of OneDrive, the file sync offering from Microsoft. Its like Dropbox, but "enterprise."

Feeling a little ashamed at what I previously would have scoffed at should I hear of it from another developer, I felt a little write up of the why and the experience could be a good idea. Now, I should emphasize that I'm not dropping Git for all my projects, just specific kinds of projects. I've been making this change in habit for projects that are just for me, not shared with anyone else. It has been especially helpful in projects I work on sporadically. More on why a little later.

So, what drove me away from Git, exactly?

On the smallest projects, like game jam hacks, I just wanted to code. I didn't want to think about revisions and commit messages. I didn't need branching or merges. I didn't even need to rollback to another version, ever. I just …

Respect and Code Reviews

Code Reviews in a development team only function best, or possible at all, when everyone approaches them with respect. That’s something I’ve usually taken for granted because I’ve had the opportunity to work with amazing developers who shine not just in their technical skills but in their interpersonal skills on a team. That isn’t always the case, so I’m going to put into words something that often exists just in assumptions.
You have to respect your code. This is first only because the nature and intent of code reviews are to safeguard the quality of your code, so even having code reviews demonstrates a baseline of respect for that code. But, maybe not everyone on the team has the same level of respect or entered a team with existing review traditions that they aren’t acquainted with.
There can be culture shock when you enter a team that’s really heavy on code reviews, but also if you enter a team or interact with a colleague who doesn’t share that level of respect for the process or…

CARDIAC: The Cardboard Computer

I am just so excited about this.

CARDIAC. The Cardboard Computer. How cool is that? This piece of history is amazing and better than that: it is extremely accessible. This fantastic design was built in 1969 by David Hagelbarger at Bell Labs to explain what computers were to those who would otherwise have no exposure to them. Miraculously, the CARDIAC (CARDboard Interactive Aid to Computation) was able to actually function as a slow and rudimentary computer. 
One of the most fascinating aspects of this gem is that at the time of its publication the scope it was able to demonstrate was actually useful in explaining what a computer was. Could you imagine trying to explain computers today with anything close to the CARDIAC?

It had 100 memory locations and only ten instructions. The memory held signed 3-digit numbers (-999 through 999) and instructions could be encoded such that the first digit was the instruction and the second two digits were the address of memory to operate on. The only re…