We recently added a new https://www.googleapis.com/auth/admin.directory.user.security OAuth scope for fetching OAuth tokens issued by a user to a 3rd party Google app. This will cause existing integration instances that have not authorized their admin user with the new scope to fail because the authorization process in validateInvocation leverages all scopes that the project can use and Google responds with a missing scope 401 error.
Partial Solution
Make each internal integration GSuite client aware of which scopes they need to authorize. Add better error handling/reporting around the Google authorization process to make it more clear which scopes are causing the failure. Additionally, we should consider adding a getStepStartStates that will authenticate with each scope to ensure we have permission to even execute a step in the first place.
Additional Thoughts
It would be great if the integration instance config contained the scopes that the customer intends to use. This would allows us to disable steps in getStepStartStates without having to try a series of authentication permutations.
Problem
We recently added a new
https://www.googleapis.com/auth/admin.directory.user.security
OAuth scope for fetching OAuth tokens issued by a user to a 3rd party Google app. This will cause existing integration instances that have not authorized their admin user with the new scope to fail because the authorization process invalidateInvocation
leverages all scopes that the project can use and Google responds with a missing scope 401 error.Partial Solution
Make each internal integration GSuite client aware of which scopes they need to authorize. Add better error handling/reporting around the Google authorization process to make it more clear which scopes are causing the failure. Additionally, we should consider adding a
getStepStartStates
that will authenticate with each scope to ensure we have permission to even execute a step in the first place.Additional Thoughts
It would be great if the integration instance config contained the scopes that the customer intends to use. This would allows us to disable steps in
getStepStartStates
without having to try a series of authentication permutations.