You're missing the point (which is hilarious, because the very first sentence of the linked article spells it out explicitly). The APIs for password hashing are simple, and always have been (c.f. man 3 crypt).
It's the problem area that is complicated and rapidly changing. And use of APIs and mechanisms that just a few years back were Best Practices is now discouraged. That's not something that can be treated by a cute Python API.
The best practice a few years ago was "use the best PBKDF available", which hasn't changed – just what algorithm to use. This isn't different from any other part of crypto – we have a constant algorithm churn as we identify and replace problematic algorithms.
And OAuth is no exception: If you implemented OAuth five years ago, it was OAuth1, which was obsolete and ripe for replacement… four years ago.
Uh... the specific advice I was replying to was precisely to use a specific python wrapper around Argon2, which is certainly not isomorphic to the "best PBKDF available" (even if it might be right now).
And the OAuth point is misdirected: we're talking about hash choices here, which OAuth is not. An OAuth1 client, while perhaps obsolete for other reasons, would certainly be protected against the need for a change in password hash, because all that stuff happens upstream and it never sees the password. That is by design, therefore remote authentication against highly-trusted password verifiers[1] is a good idea, which is what the great-grantparent post was saying.
[1] Which, sure, has its own list of worries unrelated to hash behavior.
So what is your point then? No matter what you do – whether you verify password yourself or externally – the state of the art constantly changes and you have to update your code either way. There's no escape from that. The reasons change, but not the code churn.
Uh... no. That's exactly wrong. If bcrypt or whatever gets broken tomorrow, and my OAuth provider needs to reset all the passwords in the database (Linode literally did this last week, though not because of a hash change, it's a common kind of thing), I don't need to change a line of code.
Ergo, if you're worried about changes to password hash vogues, OAuth is a good idea. Thus the point way upthread, which both you and the other poster seem to have missed.
Because it's a nonsensical point. You trade one very simple thing to worry about – password hashing algorithms, for which you can count all variations in the past ten years on one hand – with a massively complex system like OAuth (1.0? 1.0a? 2.0?), which in turn relies on TLS for transport security, for which best practices change every two or three months.
If bcrypt gets broken tomorrow, your passwords are safe until you have a data breach. If OAuth gets broken tomorrow, you're immediately at risk.
What about the code for taking initial passwords, changing passwords, password recovery, securing login forms, storing passwords, transitioning to new hashes methods and even 2-factor authentication? OAuth providers would do all this for you in an undoubtable more secure way than most people would have time for.
