This is probably at least partially blocked on T5873, which we should sort out before expanding API access.

Any update here? As far as I can tell it's also impossible to use any of the differential API endpoints using OAuth .

Please see Planning. We update tasks when new information is available, we don't have a secret shadow tracker with lots of juicy secrets that we aren't sharing.

This is the only difficult blocker for T7673, a bad behavior which is annoying and sort of user-hostile, so I'd like to at least plan our way through it.

This is probably not difficult to implement, but seems somewhat difficult to design. In particular, I would like both users and administrators to have granular control over what third-party applications are permitted to do so that OAuth isn't a convenient button which gives away the keys to the kingdom.

Maybe the flow goes like this:

• Permissions are granular: an exhaustive list of callable Conduit methods.
• OAuth Applications (in the "host" Phabricator) have controls for configuring application access. You can set each method to "Allowed" or "Disallowed". If a method is disallowed, the application is never permitted to request access for it.
• Users confirm that they want to allow access.

So an application that wants to do something needs to get permission from the administrator via the application, and permission from the user via scope workflow. That seems fairly reasonable, and better than the Facebook/GitHub/etc case because the administrator is usually not the application owner here so this is a meaningful check on application power, while they usually are in those cases so it's pointless for an application to restrict access.

One possible issue is that Conduit methods may not be granular enough. For example, providing access to project.edit allows a client to both create and update projects. T7673 will add some sort of auth.logout method -- do applications need separate permission to log out their own tokens/sessions vs log out all web sessions vs log out all sessions across all token types?

I can't really think of any use cases where this particularly matters and isn't reasonably navigable, though.

This does mean that administrative configuration of OAuth server applications will be a huge pain if they need a lot of permissions, but I think that's generally fine, and we could make the UI easier down the road.

Are there any obvious ways to see scope requirements/availability today, even if it means spelunking into the source code?

Conduit API methods define a getRequiredScope() method, which tells you the scope they require.

Today, there are only actually two scopes, "always" and "never". These methods can "always" be called (any OAuth token is sufficient):

user.whoami
maniphest.status.search
maniphest.priority.search
conduit.query
conduit.getcapabilities
auth.logout

All other methods can never be called.

@epriestley any timing/plans for expanding? Would love to replace our older user token flows with an OAuth flow. We'd need a few other methods though:

maniphest.createtask
maniphest.edit
maniphest.search
project.search
user.search

Plans, yes. Timing is trickier. Currently, we only have one outstanding request for this feature (PHI760, which mostly wants project.search). So it's in queue somewhere, but currently beyond the forecasting horizon.

Even with OAuth, you still can't make AJAX requests to Conduit from client-side JavaScript, right? Is the idea that the backend code uses OAuth to talk to Conduit on a user's behalf?