I think it is wrong and harmful for GitHub to have APis that do not allow password-based access.
OAuth is the correct solution for protecting the user from third parties who middleman the authentication at the user experience level, but only allowing OAuth and not allowing passwords is only the right design if it is never correct or useful for users to use the API directly or through trustworthy code.
It adds significant learning and code overhead - significant code surface area that the user has to audit or implement - to use OAuth. I regularly use the GitHub v3 API from memory on the command line with just
curl. It is impractical for me to do that with any OAuth-only API.
More importantly, this trend of disallowing passwords seems to be largely based on the paternalistic security premise that users cannot be trusted to not insecurely save their credentials in some file, but it reduces the maximum security possible by effectively forcing us to always store the OAuth credentials that we are allowed to use!
With passwords, I just type the password every time. With practice, this is quick and effortless even for ridiculously long and strong passphrases. So with passwords, secret credential information can be made to never hit permanent storage, and can even have its lifetime in memory minimized. But with an OAuth token? Unless you want to create a new OAuth token every single time you use the API, you have to store the token to disk.
In other words: if something like “open source wrapper for the API” sounds like a thing you want your users to be able to have, only allowing OAuth and disallowing passwords is wrong.
Unless we’re really saying that paternalistic security is the only way because the inability to trust some users to do the secure thing is worth imposing limitations and costs and a security ceiling on users who could and would do the secure thing.
(You could argue that the other security downside of passwords is that the password has to be transmitted to the server every time, but that’s a non-sequitur because that can be solved by using one of the established challenge-response approaches which do not require the password to ever be transmitted and which would still be strictly better with respect to every downside of OAuth mentioned above.)