Users want to grant 3rd party applications/services access to resources within Synapse.
For example, a user wants to use a Shiny application to summarize private data stored in Synapse. The user would want to grant the Shiny application, temporary, read-only access to the data to achieve this goal. OAuth 2.0 is a specification for granting such access.
Another use case is that of workflow execution: A user identified a workflow that has been used in Synapse with interesting results. They seek to replicate the work or to run the workflow on other data. They task a workflow engine to run the workflow, 'pointing' it to their own data. They need to authorize the workflow to access select resources under their account. (Currently they would have to give the workflow complete authority to act as if they themselves were logged in.)
Another use case is Dockstore integration. (Note, we do not at the time of this writing have a specific plan to integrate with Dockstore). This system, a catalog of 'dockerized' scientific software tools, is a thin layer on top of Github and a Docker registry (Quay.io). To get Dockstore to integrate with the Synapse Docker registry we would likely have to implement an API similar to Quay's, which includes being an OAuth provider (http://docs.quay.io/api/).
Update: We should make the distinction between (1) implementing OAuth and (2) providing scoped access tokens to clients. The latter is part of the former but can be done without a full implementation of OAuth services. For instance in the Workflow use case above, a user might go to Synapse to generate a scoped authorization code or access token that is then passed to the external app'. Since the external app did not initiate the request the authorization code redirection endpoint need not exist.
It is fantastic that we are considering implementing oAuth - we have encountered several use cases over the last 2-3 years that could have been solved by Synapse providing a standardized method of authentication. Most ended up using alternative solutions but having these in mind could help with possible future uses and design.
1) Using Synapse accounts to give access to data resources on other platforms. This has been requested a few times the specific example that I remember is project GENIE where the same data is shared both in Synapse and cBioportal. This required two accounts to access the data and manual syncing of accounts between Synapse and cBio. Even though cBio used google as an oAuth provider.
2) Shiny applications that present data from Synapse currently have to be iframed into Synapse to provide authentication using the session token. If Synapse provided authentication we could have the Shiny code run anywhere.
3) We have had multiple instances where un-authenticated visualizations services have been run on data initially stored in Synapse where it would have been trivial to add authentication if Synapse was an oAuth provider. For example CMC)
(2) and (3) are clear but I'm struggling with (1). What does it mean that "the same data is shared both in Synapse and cBioportal." Are you saying it's mirrored (each system has a copy of the same data) or that it's stored in one system and accessed via both? If the latter, which system holds the data?
In the example I mentioned the data is mirrored but users will use both systems and would ideally not need two different accounts.
I see. I don't think OAuth would solve the problem of obtaining access to resources in two different systems but there are approaches to Single Sign On (SSO) that might allow someone to sign in once with their Google password and then have access to data in both systems. In general I would avoid having multiple copies of data if possible and try to have one system link to the other (e.g., using external file handles or URL links in a Synapse wiki page).