Twitch has been adding a lot of new OAuth scopes recently. Every time a new one is added that our users want to interface with, it means we have to sign the user out and reprompt for permissions. I understand that this is supposed to be what happens, but at this point our permissions list is so long that I’m pretty sure nobody reads it and this whole process becomes more of an annoyance.
Is there a better approach? Right now, users are annoyed that they constantly have to sign in again because Twitch adds yet another OAuth scope that we have to declare.
I would also like to have a scop called “everything currently and in future after user:” but for now there is no wildcard scope. If you want to have something like this, have a look at the Uservoice-Forum: https://twitch.uservoice.com/forums/310213-developers
No not really, basically following the oAuth spec here and this is a “problem” for anything that does oAuth, new feature = new scope = need to get new tokens so you can use new feature.
Twitch adds a new thing, Twitch needs to scope that new thing.
As a user might not want to have a tool access the new thing, and a developer might not want to request access to the new thing
Only declare the scopes you need for your tool to work
If your tool implements a new feature, then you need to communicate that you support that new feature and get new permissions accordingly
If users are logging into the tool to use it anyway then getting new scopes is trivial
That is incredibly dangerous and unlikely to come to pass.
From a security point of view it would be incredibly bad practice to have a scope that would allow access to all future features so the user never has to agree to the scopes again. Similarly it’s bad practice to request more scopes than needed for the operation of your app so it’s quite uncommon to need every single scope when new scopes are added.
Even if you do need every scope that gets added, it’s usually months between new scopes being added, if not years in some cases, so requiring the user to go through the OAuth flow a few times a year is far from the end of the world, and also helps to remind the user of what permissions you’re requesting, as to if the user chooses to read that list or not is up to them but it at least must be made clear to them what your app is requesting.
It is easy to have category pseudo-scopes. I would recommend that instead of real wildcard (or “every future scope”) scopes.
They do not violate the OAuth specifications and do not introduce any new security considerations. In fact, requiring new scopes for everything has its own security considerations they can help mitigate to an extent (security fatigue).
Someone can submit a suggestion on user voice along these lines, and good luck to you if you do.
What about having a method to add a new scope to an existing token? Twitch already has the list of approved scopes, so that’s not needed. Just add the new scope, generate new token, profit.
That way, the user isn’t bombarded by having to re-auth every scope that they have already approved. The screen would just show the new scope that’s being approved.
The big issue with this for me, aside from having to nag and annoy users to re-auth, is that the auth page UI is … umm … quite bad. The UX rates 0 out of 10 for me. Design is not my thing, but I’m sure there are some designers and UX specialists that could make some major improvements there if Twitch put the resources on it.
I don’t think the OAuth specification has any sort of capability to just ‘add scopes to an existing token’. So what you’re suggesting would be going off-specification and potentially breaking every OAuth library as they’re all pretty much standardised to what the specification allows for.
As for your trouble with UX, UserVoice would be a great place to suggest what you think should be changed and how, and any potentially additions that may help you. I couldn’t find any other feature requests on UserVoice for this so it may be that Twitch is unaware of potential issues on that auth page as no one else is suggesting improvements to be made or usecases where the current design is failing them and needs change, so if you post on UserVoice that will at least start some awareness of this.
Don’t get hung up on the phrase “existing token.” I don’t see where the OAuth spec has anything to do with this.
It should be totally possible for Twitch to generate a new token with just the client giving it an ‘add_scopes’ command, for example, and the new scope(s) requested. Twitch already has everything it needs to generate a new token.
Send the user through the user auth flow again. Twitch gets the same data it had in the first place when it generated the original token, but this time it’s just adding another scope to the list. It returns the same data to the callback URL, and everyone’s happy.
Should be totally doable, and I don’t see how that would violate any spec.
I don’t use UserVoice. I don’t agree with their privacy policy, and I don’t want yet another account on yet another site I don’t need. I feel like Twitch should have their own user suggestion forum on twitch.tv.
The whole process is OAuth, so to have some sort of function to either edit an existing token or generate a new token with additional scopes and NOT list all the other scopes the the token will have will be breaking the OAuth specification. While technically it may be possible, in my opinion there is not much justification for such a change when the vast majority have no issue with the current auth process.
That’s your choice, it just means that you wont be able to voice your use cases/needs/ideas in the place where it matters. It’s not “another account” though, as UserVoice uses your Twitch account.
While a suggestions section on this forum may be suitable in some situations, it does not provide the same flexibility that is needed and used by UserVoice, such as easily ordering feature requests to the relevant team, or access control to certain suggestion areas for users under NDA needing access to closed beta areas where they can make suggestions involving products not yet public. Such access control would be more complicated on places like these forums where user accounts are not always tied to a Twitch account.
Obviously, extensions like “an ‘add_scopes’ command” are non-standard. They may not technically violate the spec, but are they even needed?
There would be nothing wrong with collapsing the list of scopes a user has already authorized for a given application. It would even be better for the user because they are being explicitly informed what additional permissions they are granting. It does not even require additional significant work on Twitch’s side (see below).
I do not know if that is true (and I’m not interested in looking it up right now). I do know that most OAuth providers do not list all scopes requested. More relevant, though, is that if a set of scopes is requested, Twitch will automatically authorize it the second time without prompting the user.
If they are required to prompt the user every time, then they are already violating this. If they are not, then not prompting the user for scopes they have already authorized does not violate this. (Also, note that my “compromise” suggestion would still list all scopes requested, just not as prominently. I’ll even go further and say they should have a link from the authorization page to manage the users existing tokens.)
This is a bit off topic
[citation needed]
You could say it’s effectively not another account because it uses Twitch authentication, but it is another account on another service.
Counterpoint: this forum is better moderated (h/t @BarryCarlyon), so the people who might act on suggestions could actually see them (at least until this forum inevitably gets buried in spam too).
Also, we know some of the developers do occasionally drop in here. It may be pretty rare, but seeing any evidence of anyone remotely related to Twitch looking at UserVoice is like a unicorn: even if you see it, people will think you’re insane if you tell them.
If a good idea is suggested here, someone who would be involved in implementing it might see it. That’s not nothing.
