Hey, everyone.
Welcome to another edition of YouTube Developers Live.
Today I'll be teaching you guys some tips and tricks
for debugging your OAuth token when you just
don't seem to be getting the right responses.
So why don't we go ahead, switch to my screen.
I'll show you some of the tools that I
use when I'm debugging OAuth.
So first off, you'll want to know about this documentation.
It's on developers.google.com.
It's called, "Using OAuth 2.0 for Client-side Applications."
It's probably easier if you just search
for this title in your favorite search engine.
Again, that's "Using OAuth 2.0 for Client-side Applications."
There's a lot of documentation here.
But really there's one thing here that we want to get at,
and that is validating the token.
So when you click on this link, you'll
see that there's this URL.
And this URL lets us validate access tokens
and lets us get more information about the tokens.
So in this case, I'm going to go ahead and just
copy paste this output here, this URL here,
and see what happens.
All right?
I'm just copying this into my browser.
And what you're going to see back
is that there's going to be a JSON response that says,
hey, the token's invalid.
So that's because I just copy pasted this.
In fact, if I give it some crazy value, abcdef,
you'll see that this is still an invalid OAuth token.
And that makes sense.
So what happens when we give it a working OAuth token?
Or one that's semi-working?
Well, first we'll need to generate one.
And a tool that I like to use to generate OAuth tokens
is the OAuth Playground.
You can get here by going to developers.google.com/OAuthPlayground.
Or again, you can search for this in your favorite search
engine until it comes up.
Now, what I'm going to do is I'm going to select and authorize
some APIs.
So I'm going to scroll down.
I'm going to look for YouTube, and I'm
going to select the YouTube read-only scope.
I'm going to scroll down to Authorize APIs.
And this is going to put me through the three-legged OAuth
flow.
I'm going to click Accept.
And you'll see that I've gotten back an authorization code.
I'm not going to go too much into the internals of OAuth.
But the authorization code is something
that your server would use to exchange
for a refresh token or an access token.
So if I go ahead and I click Exchange authorization
code for tokens, it will populate the Refresh Token
and Access Token fields.
And in the OAuth 2.0 Playground, I
can actually test certain API calls.
We're not going to do that today.
Instead, I'm just going to go back and click
on Exchange authorization code for tokens.
I'm going to copy paste the access token.
And I'm going to put it into this URL.
And you'll see that I'm just passing it as a URL parameter.
And I get back a lot more information.
In fact, I see what's the client ID that got it back.
What's the scope, and when does it expire,
and what's the access type?
Now, you may or may not be using an offline token.
So this is one way to know if you
have an online token or an offline token.
And remember, an offline token is one
that you can refresh every hour, via the refresh token,
and get a new token to make API calls with.
Now, most of the time, the API client
will handle this for you.
So a lot of times, people get confused.
You know, what's an authorization code?
What's a refresh token?
And the token that you want to use to be making API calls
is the access token.
So if you accidentally plug in your refresh token somehow,
you'll see that, hey, this is not a valid OAuth token.
And what's really cool about this
is that I can go ahead and switch to terminal.
And I'm just going to blow this up right here.
You can also do this in cURL.
Oop!
You're going to have to give it some quotes there.
And what's nice about this is that any HTTP client
can handle this operation for you.
So one possible thing you can do an error situation is
to say, well, did I screw up here?
And you can insert some debugging code
that says, if an exception gets thrown,
if there's a 400 or 401, you can use this token info
URL to be able to validate that you actually
did get the right type of token.
A very common error is that a token doesn't
have the right scope, or the token is expired.
So you need to have a valid OAuth token
before you can make API calls.
So that's just a little trick that I like to show people.
So again, to recap, there's a document on how to do this.
It's called "Using OAuth 2.0 for Client-side Applications."
You can just search for that title.
And another tool is the OAuth 2.0 Playground.
Typically, in these situations, you only ever
need to implement it one time, and you
don't need to worry about this again.
You save the refresh token, and you
can keep making calls with the access token.
So before I go, I'm going to show
you guys one more trick, which is that the OAuth 2.0
Playground uses the client ID ad client secret-- it's
one of our client ID and client secrets.
So if you want to see the full request and response using
your own client ID and your own client secret,
click here under Settings.
And you can see that there's different settings here.
Most of the time, the one that you want to change
is Force approval prompt or Use your OAuth credentials,
and this is where you would plug-in your own client ID
and client secret that you're getting from the API console.
Because once you get this, you can start making API calls.
And you can compare these against your own API calls
to see what the difference is.
And hopefully, that'll help you guys debug.
So that's all I have for you guys today.
Hopefully, this helps you guys with any problems
you may have as you're trying to figure out what's going on
with your OAuth tokens, and help you authorize so you can go
ahead and build great YouTube applications.
All right.
Thank you all very much.
And have a great day.