>Maybe because they are old accounts that pre-date YouTube being purchased by Google?
Yes, that's right. I archive YouTube videos, there are several URL formats for YouTube channels.

/user/${USERNAME} - If you signed up before 2014 or something like that, you have one of these.
/c/${CUSTOMNAME} - After 2013 or something like that, you could make a "custom" name that you could change at will if your channel was 'approved' to do so by The Algorithm. Deprecated.
/${NAME} - One of either a /user/ username or /c/ custom name. Which one takes precedence in a conflict, I have no idea.

/channel/UC${REALLY-LONG-STRING} - Somewhere around 2011 YouTube started giving everybody one of these. If a channel doesn't have a /user/ username or /c/ custom name, this is the only way to refer to a channel that can't be changed by the channel owner (i.e. permalink). I think the "UC" stands for "user channel", because you can change it to "UU" ("user uploads") as the argument to a /playlist?list= to get a playlist of all the videos on a channel (don't tell anyone or they might "fix" it). YouTube is trying very hard to hide this since they started giving out "at symbol" names, it can now only reliably be found in the HTML source in a "link" element with attribute rel="canonical" href="foobar". If the channel has "Watch All Uploads" available on the home tab of their channel, it can also be found there as the /playlist?list= parameter (with UU instead of UC).

@${NAME} - As of some years ago, now everybody gets an at symbol name too. If you have an existing /user/name or /c/ustom_name, it defaults to this (don't know which one takes precedence in a conflict). If not, it looks like it makes something up based on the "real name" field with some numbers added. At symbol names cannot be referred to without the at symbol like the old /${NAME} format.

In reply to jwz.

It is the new (as of 2020) name for G Suite (i.e., the Google apps under a custom domain name used by businesses) aka Google Apps.

In reply to jwz.

"I love the smell of LLMs in the morning"

In reply to jwz.

Trying to use any Google API as a mere user is so hilariously user-unfriendly.

In reply to ggn.

Is it ever gonna let you down?

In reply to jwz.

for 🦊 sake!

In reply to jwz.

Is the app ever gonna give you up?

Guess what! Google is making me write another placebo privacy policy, just to authorize a login token to my own YouTube account. (It's a password. But they call it an "app".)

And they rejected it because in the snark-assed privacy policy for my "YouTube app" I can't use the word "YouTube" because "it could potentially confuse users and lead them to believe your app is officially affiliated with or endorsed by Google".

The "YouTube app" for logging in to "YouTube" can't say "YouTube".

In reply to jwz.

Bummer...
I'm guessing this won't work for your use case because YouTube requires a "real" access token for some API calls, and API keys only work for reads...

Sorry for wasting your time.

In reply to David.

GET https://www.googleapis.com/oauth2/v1/tokeninfo?key=API_KEY
400: Either access_token, id_token, or token_handle required

GET https://www.googleapis.com/youtube/v3/channels?mine=true&part=snippet,status,contentDetails&key=API_KEY
401: The request uses the mine parameter but is not properly authorized.

In reply to jwz.

You can pass the API key directly in the URL for v3 API calls, e.g.  `GET /youtube/v3/search?key=[API key]` (instead of the `Authorization` header with your access token).

In reply to David C.

I have no idea what that is or how I would use it.

Have you considered creating an API key instead of using OAuth?
(YMMV, not sure if it requires a paid account; also it's only for API v3)

In reply to jwz.

And if I authenticate with any of those older "projects" besides the 2024 one, every request fails with "quota exceeded", even though they have not been accessed in years.

In reply to jwz.

OMG I just stumbled across a page of detritus showing that I have been fighting with this crap for 14+ years...

In reply to jwz.

Yes. That's a rabbit hole I also did not descend into...

In reply to jwz.

OK, sorry. I'm out of ideas at this point. If it is any consolation, it is them and not you.

In reply to Dave Slusher - Tech Stuff.

Yup I just did that and it sent me down a branding verification rathole, see elsewhere in the thread...

In reply to jwz.

well you already wrote a privacy policy for Google might as well link to it from YouTube.

In reply to jwz.

OK, try this:

In your Google Cloud thing, under Auth look in Audience. If your app is in Testing, you need to publish. I created one just now to try to find these options and that is what it defaulted to. This is also in a place where no sensible person would ever look for it.

In reply to jwz.

Is your application for personal use only?

[x] Yes [ ] No
If your app is not shared with anyone else or it will only have 100 users personally known to you, set your project's publish state to Testing. Production apps for personal use are not reviewed and will show the unverified app warning during sign-in.

Your app could not be submitted for verification for the following reasons:
Your application is for Personal use only

In reply to Philipp Riederer.

Ok, it does seem to be set to testing, but when trying to change that I am now being sent down a rathole of "Branding verification issues"

Your home page URL does not include a link to your privacy policy.
Make sure your home page includes a link to your privacy policy. Learn more
Your home page does not explain the purpose of your app.

Jesus Fucking Christ.

https://developers.google.com/identity/protocols/oauth2#expiration says that the refresh-tokens expire after 7 days if the client is set to "testing". You should see the publishing status [here](https://console.cloud.google.com/auth/audience) (Google Auth Platform -> Audience).

In reply to Dave Slusher - Tech Stuff.

I did at one point stumble across some documentation claiming that the refresh token lasted forever unless the token was unused for >6 months. When I read that I thought, "welp that's clearly not what's happening".

In reply to jwz.

It's OK, this stuff is a nightmare. I have totally done this but in the past so my information has rotted. Is it possible the eternal one was created in the past and the 1 week expiration is more recent?

I walked through creating an OAuth app and could not see any options for controlling expiration. I'm suspecting this expiration is automatic, out of your control and changed over time.

In reply to Dave Slusher - Tech Stuff.

I don't know how to answer that question...

In reply to jwz.

Sorry, forgot to ask. Is this the Data API or the whatever the other one is, regular API that allows for control and creation.

In reply to Dave Slusher - Tech Stuff.

I see a line that says "Status: Enabled" in the "Additional information" sidebar on the right. Is there a different place to look?

I think the last clue is the relevant one.  I've had the same problem.  While I don't remember how I resolved it, it rings a bell that the desktop client doesn't expect to re-up the refresh token, while web clients do. (Or, I presume, iOS, but I work in web and once accidentally set up an account as desktop).
Not 100% on that, but I'd focus on the client type too.
That said, google apis often fail without error codes and do other unpredictable things, so it could also just be google being google.

In reply to Mark T. Tomczak.

I don't know what a Google Workspace account is, so probably not?