Dedicated readers of this blog will remember our post from a few months back entitled “ClientLogin #FAIL”. In it, we laid out a number of scenarios in which attempts to use ClientLogin authentication would result in an error (and urged developers to move off of ClientLogin in general). The first failure scenario involved users whose YouTube account is not linked to a Google Account. Fortunately, the number of YouTube accounts in that unlinked state has decreased greatly over the past few months, so failures of that sort with ClientLogin are not as common now.
There’s another related failure scenario that we want to bring to everyone’s attention, this time involving both AuthSub and OAuth (collectively referred to here as “auth”) tokens. Starting on Wednesday, August 31, if your code attempts to use an auth token that was generated for an unlinked YouTube account, your request will fail with an HTTP 401 response code indicating that the token is invalid.
It’s important to note that what determines when the token is invalid is whether the YouTube account was linked at the time the initial auth token was generated. For example, if your code generated the auth token for an unlinked YouTube account on March 1, and then the user linked their YouTube and Google accounts on March 2, the auth token will still be considered invalid.
On March 31 we started to enforce the need to have a linked Google Account as part of the AuthSub and OAuth login flow, meaning that it was impossible to generate an auth token for an unlinked YouTube account after that date. So this change can only affect auth tokens generated before March 31 of this year.
While auth tokens normally don’t expire, users have the option of manually revoking them. If your code uses a revoked token, you’ll also get back an HTTP 401 response. If you’re using a client library, it will generate an exception to indicate the failure. It’s a best practice to make sure that your code handles invalid token errors by asking your user to go through the AuthSub or OAuth login flow again, storing the new token value and discarding the old one in the process.
If you have any questions about YouTube API authentication, please let us know in our developer forum.
Cheers,
—Jeff Posnick, YouTube API Team
There’s another related failure scenario that we want to bring to everyone’s attention, this time involving both AuthSub and OAuth (collectively referred to here as “auth”) tokens. Starting on Wednesday, August 31, if your code attempts to use an auth token that was generated for an unlinked YouTube account, your request will fail with an HTTP 401 response code indicating that the token is invalid.
It’s important to note that what determines when the token is invalid is whether the YouTube account was linked at the time the initial auth token was generated. For example, if your code generated the auth token for an unlinked YouTube account on March 1, and then the user linked their YouTube and Google accounts on March 2, the auth token will still be considered invalid.
On March 31 we started to enforce the need to have a linked Google Account as part of the AuthSub and OAuth login flow, meaning that it was impossible to generate an auth token for an unlinked YouTube account after that date. So this change can only affect auth tokens generated before March 31 of this year.
While auth tokens normally don’t expire, users have the option of manually revoking them. If your code uses a revoked token, you’ll also get back an HTTP 401 response. If you’re using a client library, it will generate an exception to indicate the failure. It’s a best practice to make sure that your code handles invalid token errors by asking your user to go through the AuthSub or OAuth login flow again, storing the new token value and discarding the old one in the process.
If you have any questions about YouTube API authentication, please let us know in our developer forum.
Cheers,
—Jeff Posnick, YouTube API Team
