It’s “industry standard oAuth”, so a lot of services use this authetication mechanism for third party access to data, Twitch, YouTube/Google, Twitter, Discord to name a few. It’s all oAuth to get access
it can be done with type=token, but then you need to capture and store the token. Then after then token expires the streamer will need to reauthenticate and provide a new token
With type=code you exchange the code for an access_token and refresh_token then you can use the refresh_token when the access_token expires.
The ClientID creates a “name” for your script so the streamer can see and disconnect it/know what they are linked it/granted permissions to on Twitch
The owner of the clientID is irrelevant.
The ClientID + a constructure oAuth link, will create a link between the authenticating user, the scopes and the clientID to generate an access_token aka password to access the authentication users account and read/write data about the account, if relevant scopes granted.
So if I want to read channel points for lirik, I would ask lirik to go to my website and click the link, grant access and store the returned token.
If I want to read channel points for ninja, I would ask ninja to go to my website and click the link, grant access and store the returned token.
If I want to read channel points for cohhcarnage, I would ask cohhcarnage to go to my website and click the link, grant access and store the returned token.
In all three examples it’s all the same ClientID, mine.
A ClientID doesn’t give you immediate access to the Streamers account. There is no connection between a ClientID and a Twitch User.
A clientID only “exists” on dev.twitch.tv it doesn’t link to anything on twitch.tv until you do an oAuth loop and a user creates an access link betwen their account and the clientID.
Any clientID can obtain scoped permissions to a Twitch User Account.