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.