Using the root URL (/kraken/) with a token gets me the user name and user ID associated with that token (and it’s validity), but nothing else. If I’m authenticating a user using oAuth, why does it take 3 requests to get their public information (one to trade their auth code for a token, one to validate the token and get the username/id, and one to look up the user details)? You’re already giving me the username and id, why could you not also give the display name, logo, bio and the like?
The /kraken/user endpoint exists for that.
Except I don’t want, or need, private information - I don’t want to have to declare the user_read scope, I just want the public information the user provides.
Yes, but that’s an extra step. So for each user logging in, I’m making 3 requests (and they’re making one), which seems suboptimal, and an un-necessary load on your servers.
An extra step you need to do once per user in your application. Not once per visit or page load. Store the ID.
I’m confused. It takes one request to https://api.twitch.tv/kraken/users/44322889?client_id= to get all of the public information about a user including display_name, name, and bio. What other two requests are you talking about?
It might also be worth noting that your suggestion to go from 3 requests, to 2 by including user information in the root kraken endpoint would increase load for every single request to that endpoint, even those that only needs information about the status of a token. There could be apps that regularly check the status of their stored tokens to see if any are no longer valid, or have out of date scopes, and your suggestion would mean each time those checks are performed the API would also have to retrieve user data for every single one of those tokens being checked, which could potentially be hundreds or thousands of tokens.
Here’s the flow, when logging in a new user.
- Server receives access code from user after they log in to Twitch.
- Server accesses /kraken/oauth2/token to trade access code for token
- Server accesses /kraken/ to lookup username and id from token (and verify token is valid, with required scopes)
- Server accesses /kraken/users/ to get public information like display-name and logo.
- Server can finally display welcome to user with their desired Display Name and Logo.
That’s 3 steps the server has to do, and 3 requests to various parts of the Twitch API, to get the public information about the user that just logged in. This is all for the same user each time.
Server receives access code from user after they log in to Twitch.
- Server accesses /kraken/oauth2/token to trade access code for token
- Server accesses /kraken/users/ to get public information like display-name and logo.
Just called /kraken/users/ don’t bother calling /kraken/ and process the error reponse from /kraken/users/ as needed
Except that that endpoint requires user_read. I don’t want, or need, their private information (Data protection and all the rest), all I want is the public information.
Don’t send the user thru the oauth loop at all, just ask them for their twitchusername, then it’s two calls total, a call to convert username to id (once) then fetch /kraken/users/$id periodically.
Which works if you are not using Twitch oauth as your logged in/out to your site controller.
Except I want to verify that the user is who they say they are - I want the user to be able to control and customise what this bot does in the user’s channel, so I need to make sure they are the channel’s owner (or a channel moderator, but that I can’t check from the API at all, so I’ll have to keep track of that separately).
You do realize you’re complaining about an extra ~85 bytes you need to send, because you need to use an ID instead of username, right?
I’m not complaining about an extra 85 bytes, I’m complaining about another round-trip to the server. Each round-trip is a potential point of failure, and a network and processing delay while I send data out, wait for the server, receive data back and process that data. It’s 3 GET requests happening sequentially (as they can’t be parallelized because each relies on data from the one before), all of which the user has to wait to complete before they get any kind of response.
In a perfect world, exchanging a code for a token would return the token, the scopes it’s for, and the username, id, display-name, bio and logo (the public information) of the person the token is for. That way you’re not left holding a token with no idea who it’s for. It can be assumed that if you’re exchanging a code for a token, that the token you get is valid.
I understand that exchanging a code for a token is part of oAuth, and I understand that it may break the standard to introduce extra information at that step, but it shouldn’t/wouldn’t break anything (except, perhaps a very badly written JSON “Parser”) to return extra information with the token’s details when it’s generated from an issued code.
Currently, I can’t get ODIC working using the Authorization Code flow.
(User) Request-> https://api.twitch.tv/kraken/oauth2/authorize?response_type=code&client_id=[clientid]&redirect_uri=[redirecturl]&scope=openid&nonce=[SessionID]
Receive <- address?code=[AuthCode]&scope=openid
(Server) Request-> https://api.twitch.tv/kraken/oauth2/token?client_id=[clientID]&client_secret=[clientSecret]&grant_type=authorization_code&redirect_uri=[redirectURL]&code=[AuthCode]&_method=post
Receive <- { access_token=[AccessToken], refresh_token=[RefreshToken], scope=[openid] }
It’s not giving me the id_token, so right now, that’s not a useful option.
How do you justify the additional database load? We don’t know Twitch’s database design, but you have to consider that what you’re suggesting means an additional database lookup to retrieve user details to add to the response. As you already know there’s an endpoint for retrieving user data, so what this would be doing is duplicating that functionality and increasing load (albeit very small) on the root kraken endpoint.
Like I said though, I don’t know Twitch’s database design and maybe adding extra fields like these to the response could be negligible but personally I don’t believe there is a real use case for this as sure it might save you a few milliseconds by reducing the number of API calls you have to make but this process only happens the first time someone uses your app, so even if you have a thousand users that really doesn’t add up to much reason to bloat that endpoint for everyone when most apps (from my experience) will be using a token with a user_read scope and getting the user details anyway as being able to check that they have an verified email address is a handy little security feature.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.