Incremental Authorization Practices

I’m working on a project that will require pretty extensive access to a user’s account, but I obviously don’t want to ask for all of the required permissions up front and freak them out. Fairly common practice is the incremental authorization of scopes as they become needed so that the user can more granularly decide what they allow access to based on the specific features they want to use. However, I have’t been able to find anything about incremental authorization in the docs or any conversations about it here.

So my question is, what steps need to be taken to implement this kind of incremental authorization of scopes?

My one thought is to start with just a normal OAuth flow that requests the super basic access when they sign up, and then just essentially do the same thing with subsequent scopes; do these subsequent tokens include the previously granted scopes or will I be handed a new token that works with the new scopes and have to hang onto the old token to use the old scopes? Does this change at all if I set force_verify to true? Or will I have to do something like set force verify to true and just include all of the scopes that they have verified in the past and assume they’ll provide that authorization again for previous scopes plus the new ones? I’m afraid that last option would have some of the same problems as just asking for all the permissions up front by seeing all the extensive permissions listed together at one time as they continue to authorize permissions to use more and more features.

Any information anyone could provide would be much appreciated! Thanks so much!

Twitch doesn’t really do incremental.

For what you describe just ask for scopes, and then ask for more scopes. The confirmation dialog will list ALL the scopes everytime time, not the “new” scopes.

If you send a user round oAuth with the same scopes as last time then it won’t prompt. force_verify forces the prompt.

Basically it will look scary.

@BarryCarlyon I just did some testing and I think I found a way around that. Hopefully this makes sense.

When a user sign up for your service you just request really basic scopes. Then later on you can request access to more scopes to allow them to use certain features they want to use by including just the new scopes in that authorization request.

What this results in is having two sets of access and refresh tokens for the two times you requested access to different scopes.

This obviously isn’t ideal so what you can do is then send them through the oauth flow again with force verify set to false and in that request just include all of the scopes they have authorized across the two tokens and they’ll get redirected back to you automatically with a new combined token.

That then means you have to track and monitor Two (or more) sets of keys per user instead of one. Which is just added complication and MORE sets of keys that need to be refreshed.

It works sure, but is it worth the extra complication.

Not quite actually. Here’s the whole flow to hopefully clarify things.

  1. I request just user:read:email, the user approves and I get token 1 (T1) and save it to my database.
  2. Later on I request just channel_feed_edit, the user approves and I get token 2 (T2).
  3. Then immediately after I receive T2, I grab T1 from my database, ask the API what scopes are approved on it, and combine them with what was just approved in T2, so then I request user:read:email and channel_feed_edit together and since force verify isn’t enabled and they have already approved both of those scopes in the past (even though they were in separate requests) the authorization happens automatically and I receive T3 which simply has the scopes from T1 and T2 combined. The user doesn’t notice this has happened as it’s just 2 extra redirects. Now I can forget T1 and T2 and just use T3 so I simply replace the database entry for T1 with T3.

Then if I need to add yet more scopes to my token I just start the process over, treating T3 as T1.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.