Here's where things stand now:

• We have an OAuth2 server application.
• We previously had a functional client (I think?) that never quite got enabled. It didn't survive the last round of auth refactoring, but it should be straightforward to clean up and get back online.
• T887 covers restoring it on top of the newer Auth framework.
• Once it's working again we can write some documentation.
• I also want to make some tweaks to make it more difficult to configure in a way that could be vulnerable to open redirects, HTTPS-stripping through redirects, etc.

I don't think this is very much work, and we can probably do it fairly soon. Stuff that's more work / further out:

• Once you authorize with OAuth, you'll need to call Conduit. I think this is more work than it should be right now, but there's a working Node.js client in a Paste somewhere that I can dig up, or we might be able to fix this to be a bit simpler.
• OAuth will essentially only give you access to the user.whoami method right now. We need to figure out what we want the grant model to look like before opening this up more. For example, we could have clients enumerate every method they need, but this is probably inconvenient for application authors and needlessly complex for users. On the other hand, very coarse permissions ("all methods", or "all reads") are probably not appropriate in most cases. It sounds like you probably don't need this anyway, though.
• You'll need to do a server-side workflow (e.g., have Node.js call Phabricator, not the user's browser) for now. We can probably build a client flow eventually but don't have any immediate plans to do this.
• Although I think we can get this working in the near term, we may need to tweak it a bit in the future, so just a general caveat that this will be at beta stability levels. For example, today you'll get a 50x50 profile image (I think) but in the future it will be a 100x100 profile image, and we might add more fields to user.whoami in the future, etc.
• We probably aren't going to write or maintain plugins for auth frameworks (like passport-github) in the near term. T4200 has some general reasoning about why we don't currently build very much last-mile code. Basically, we have limited engineering bandwidth and anything where we have to write/maintain a bunch of adapter code that interfaces with unfamiliar systems is usually not the best use of our time right now. The OAuth2 thing will work like every other OAuth2 thing does, though, so I think it should be easy to write this yourself (e.g., copy/paste the github one and change "github" to "phabricator", then tweak a couple of properties and URIs).

If that sounds reasonable, I'll try to get the client+tweak+write docs part of T887 done pretty soon.

Awesome, cant wait!

I am going to merge this into T7303, which is a slightly narrower task describing OAuth access to Conduit.

We restored Phabricator's OAuth server circa Jan 2015 (per T887, above) and have used it to authenticate access to the Phacility cluster for about a year. However, the Conduit access model remains flimsy (you basically only get access to user.whoami) since we don't need this in the cluster, making it fairly useless for anything else. It also hasn't been documented or polished to be more reasonable for users to configure, since it doesn't really make sense to do this work before you can do anything useful with it.

T7303 describes making OAuth access useful, so that's also the pathway forward to making this easier to use.