Previously granted scopes are lost when re-authenticating

API Feedback
1

It seems that scopes are lost when re-authenticating again with lower scopes than what was given.

For example, if the user authenticated previously gave permissions to the scopes identity identity[email], and my login flow is asking only for identity (as is best practice when logging in), the new auth token will now have lost the identity[email] scope!

Other OAuth2 implementations (such as YouTube, Discord, Twitch and Github) retain the previously granted scopes.

this is particularly harmful if you log in both creators and patrons who need different sets of scopes, asking a patron for campaigns.memberships may scare away the patron!

2

I believe that has been the case since a very long time? The new token gets the scopes that are asked?

this is particularly harmful if you log in both creators and patrons who need different sets of scopes, asking a patron for campaigns.memberships may scare away the patron!

Can you solve this by having 2 different points for starting the flow for creators and patrons?

3

No because if I want to onboard a creator vs a patron, and ask different grants from them, when I allow either of them to login and use the identity scope, the other scopes are lost and I need to ask the user to go through the auth flow again (which they just completed!).

I believe that has been the case since a very long time

Doesn’t make it correct :frowning:

4

No because if I want to onboard a creator vs a patron, and ask different grants from them, when I allow either of them to login and use the identity scope, the other scopes are lost and I need to ask the user to go through the auth flow again (which they just completed!).

So, the user goes through 2 different oAuth flows, ending up in two different tokens being created, and the last token has only the latest scopes that were asked in the second flow - therefore, meaning that the first token and its scopes are now lost, is that right?

5

Yes that’s correct. To summarize, here is an example:

First flow: User registers (scopes: identity identity[email])
Second Flow:

  • Patrons go through another flow (scopes identity identity.memberships)
  • Creators go through another flow (scopes campaigns campaigns.memberships)

… time passes …

User comes back to the website, wanting to log in (because session expires or what not)

Third flow: To login again, they go through another flow (scopes: identity)

There are 2 scope losses here, identity[email] is lost for the first time, but this is okay since I keep the email address anyway. The third flow is actually where the problem arises, since I don’t know who is logging in, I can’t just clump all scopes together (well, I can but it will be confusing since it’ll look like a lot of scopes for no reason!).

In the future I plan to merge the first and second flows together for smoother experience but that will not address the issue. Another way I could fix this would be to give patrons and creators different logins but the chance of a user error is too great to take this route, as if a creator accidentally logs in as a patron the scopes will be lost anyway.

Other OAuth APIs support this by merging past scopes with every new approval. This is how OpenID is supposed to work as well.

6

Is there a specific reason for having the users go through two flows? It feels like the first phase could be merged to one by asking the relevant scopes in one go. Many large creators and partners use such formats and they seem to work well.

Also, by directing patrons and users to two different flows via something like ‘Sign in as a Patron’ and ‘Sign in as a Creator’, it feels like you could avoid the potential worries about scopes from the patron’s side.