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.
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.