Is there any way to characterize the risk of granting access? I understand, from the nice Asana API pages, that this is only done by granting a temporary, refreshable-every-hour token, which can only be used alongside the client app’s already-registered token. (I’m probably misusing some terminology here.) With so many integration tools (IFTTT, Zapier, others), I think twice about whether I want to authorize each one.
Even if the risk in (1) is low, I, and organizations (enterprises) I’ve worked with, understandably, would not want their data accessible in such a way. That is, if I as an Asana user am a member of Org A and Org B, and I want to do some automation with Org A and they’re ok with that but Org B isn’t, what’s my recourse? Have you considered tokens that would apply to a single Organization/Workspace? Or even a way for me in Asana to designate a set of Workspaces/Organizations that a single token would apply (but not to all the others I’m a member of? Another use case is for me to do personal automation but not put at risk any other Workspaces/Organizations. Different logins would isolate things but that’s not convenient in many cases and not how I’d prefer to work in Asana.
Bumping this topic after a long time because I’m still interested in the answer, and it’s timely again for me now.
It’s a two-part question. Re part 1 perhaps there’s no great way to quantify, and that’s fine. Re Part 2, I am interested in this for myself and others I work with and would be surprised if it hasn’t come up before by others. I’d like to try more third-party tools requiring authorization, but I would like to have a choice of what organizations (at least) that I expose to each:
Is my only recourse to test tools using another (isolated) login? And if I intend to begin using a third-party tool, is there any recourse now, or plans in the future, to have this be more granular that all or nothing?
Hi @lpb, maybe I can answer some of those questions.
Currently, when you grant authorization to an app, that app can do anything you can do within Asana as long as it’s supported by our API. The OAuth spec supports the concept of “scopes” that can be used to limit what actions an app can take, but the Asana API hasn’t defined comprehensive scoping yet, so it’s effectively “all or nothing” for the time being. We have thought about what OAuth scopes might look like for Asana, but haven’t had the resources to invest in it fully. However, you can always manually revoke an app’s authorization from the “Apps” tab in your profile settings.
We have been thinking about “workspace-scoped” tokens for a while, where a user could limit an app to only working in one or a subset of their workspaces. There are a lot of questions surrounding this idea and we’re working on getting them answered, but again haven’t had the resources to invest in building and rolling out scoped tokens. Right now, the only way to prevent apps from accessing other domains is to maintain different Asana accounts. We’re aware that this is not ideal for many users and are keeping it in mind as motivation to move towards a workspace-scoped API.
At this time, we’re unfortunately unable to commit to any timeline or plans for either OAuth scopes or workspace scoping.
Another thing to note: as part of our enterprise tier, admins are given a feature that allows them to whitelist specific apps for their organization. Apps not approved by the admin are blocked from the API and cannot be used by any members of that organization.
Thanks very much for the thorough reply @Joe_Trollo!
The workspace scoping token concept would certainly work well for me and I hope that makes it into the product soon. I think both the ubiquity of Asana, and third-party tools, as time passes will continue to increase the need for this even further.
@Joe_Trollo, I’m a new Asana Ambassador and found this thread after looking over the API scopes in the documentation. Since the default scope still provides access to all API endpoints, I have a question about how this could be optimized.
When I think about fine-grained scopes, I think about it either vertically (a single workspace or project) or horizontally (all workspaces or projects).
I’m happy to be wrong about the following assumption about the user experience, but wouldn’t:
Vertical permissions be a business process made by a project/workspace manager
Horizontal permissions be a technical decision made by technical stakeholders
Thus, my proposal is to avoid a user to provide an integration with workspace-level permissions. A user of an integration could only provide fine-grained scopes for each type of resource.
Here’s an example:
Only project and workspace managers can provide access for an individual workspace or project
When a 3rd-party wants to integrate with Asana, that integration can access a type of resource if a user permits
Even if the user permits the integration access, the integration will only be able to allow automations if the workspace or project manager has provided that user access.
If the user does not have access to a specific project or workspace, it is the job of the integrator to show that error to the user
It’s clear that every type of resource (ie., user, custom field, project, etc.) has a ‘resource-type’ field. Would this design be more technically feasible and closer to the user experience?