If we change the list of required scopes for our listed App, do existing users need to re-authorize the app? Do existing authorizations (ie the tokens acquired by them) get invalidated?
Are there any risks to existing users of the App when those are changed by the App owner?
@russellbevy wrote:
If we change the list of required scopes for our listed App, do existing users need to re-authorize the app? Do existing authorizations (ie the tokens acquired by them) get invalidated?
Are there any risks to existing users of the App when those are changed by the App owner?
When changing the required scopes for an app, existing users may not necessarily need to re-authorize the app. It depends on how the authorization process is implemented and whether the changes to the scopes affect the permissions granted by existing tokens.
If the changes to the scopes result in a more restrictive set of permissions than those granted by existing tokens, users may need to re-authorize the app to grant the additional permissions. However, if the changes do not impact the permissions already granted by existing tokens, re-authorization may not be required.
That said, there are potential risks to existing users when scopes are changed by the app owner. If the changes result in broader or more sensitive permissions being granted to the app, users may unknowingly expose their data or grant access to additional resources without their explicit consent. This could potentially lead to privacy or security concerns.
To mitigate these risks, app owners should communicate any changes to scope requirements clearly to users and provide them with the option to review and re-authorize the app if necessary. Additionally, app owners should ensure that their apps adhere to best practices for handling user data and permissions to minimize the potential impact on existing users.
@HMir wrote:
… shortened …
If the changes to the scopes result in a more restrictive set of permissions than those granted by existing tokens, users may need to re-authorize the app to grant the additional permissions. However, if the changes do not impact the permissions already granted by existing tokens, re-authorization may not be required.
… shortened…
Thank you for the thoughtful reply. The case with which I am primarily concerned is a reduction in the number of required scopes for the app in order to meet best practices of “minimal necessary”, but learned after the fact of initial implementation. E.g. the completed implementation did not need one or more scopes that it was requesting based on unclear requirements at the beginning of implementation. I can be sure that the actual implementation using the tokens needs only a strict subset of the scopes originally requested when the token was issued.
What is not clear to me, though, is if the existing tokens get automatically invalidated if the required scope list for the app is reduced. Will they continue to function and be refreshable? Or will a new authorization by the user be required to issue new tokens with the revised, minimal required scope set? Is this a potential risk?
We will happily be communicating to users that our solution is using a lesser set of required scopes, improving the security position of the app. But we also want to be able to communicate with users beforehand if reducing required scopes will require action by them (re-authenticating).
Hi,
We are having question related to this topic but slightly different concern.
We are implementing new feature to a running integration. This required new scope crm.lists.write.
Currently our app are using bellow scopes:
We want to check if this new scope to the app will impact the current users who already authenticated to the current scopes in case they are not using the feature that require the new scope s(API requests not call to the action require CRM.List.Write)?