Sure, so would I help people asking me in good faith for help migrating away from Oauth2 to PAT.
you could say that that last part makes me a hypocrite, but this is still infinitely more than anyone in “camp Basic Auth/PAT” has offered so far).
Here, I just did, so we’re equally altruistic now! 
But I don’t think that your comment was fair to @NorthCrab at all - dude has not only offered (see start of this thread and connect to this thread) but is actually actively working on implementing all of that (and much more). You might not think that it is a good idea or worth it (or are just not aware of it despite being mentioned several times in this thread alone already), but saying that he’s hasn’t put an effort is just not true.
I would like to, but there’s a lot of other stuff I spend my time on. Having a 48h day has been on the top of my wishlist since I’ve been a teenager.
That I agree with, and even had idea how to make it work in zero sum game - double the number of hours in a day, and to compensate, reduce the length of workweek for (about) a half. Sadly, no success with that idea yet 
More seriously, note how I in pretty much every post here have advocated for using an existing library, and at no point that anyone should learn OAuth (any version) past what is needed to use the library
Well, it seemed to me differently at the time; but not dwell on it and to illustrate my main concern, allow me to paraphrase popular saying “There is no cloud, only other people computers” for this situation: “there is no simple Oauth2 - only shifting complexity, trust and maintenance to someone else (and hoping for the best)”
Now, one might claim that it is always a good idea to use overly complex solution, and then use pre-made libraries to abstract that complexity away – but I’d disagree on that “always” part. I’ll concede that doing that is sometimes indeed needed and a best solution. But not always. ObXKCD #2347.
That fact that I’ve seemingly so heavily contradicted myself in the same post should’ve been dead giveaway to reread the paragraph more carefully and notice that this “access” word before “security” was emphasized - probably for a reason. So to clarify what I meant by “no extra access security”:
- situation (A) - someone has MitM you and stolen your basic auth username+password to access the api.osm.org
- situation (B) - someone has MitM you and stolen your Vespucci Oauth2 bearer token for api.osm.org
My claim was: in both situations, attacker now has equal access rights to api.osm.org under your credentials, thus access security to api.osm.org between those two situations is not different.
As for other advantages and disadvantages of Oauth2, as you correctly noted, I enumerated them in that same post, so I won’t needlessly repeat them here.
Your list of advantages and disadvantages has some merits (though there are also points that I find questionable), but a big part of software engineering is about trade-offs
Thank you! What I’d like (and what I’ve hoped for, and actually actively invited people with that “did I miss any more?” bulletpoint there), is to have conversation about those points that you disagree with, or which I’ve failed to mention.
Sure, OAuth 2 has drawbacks, but they are over-weighted by the benefits.
…And after we have worked out a table of pros & cons that we can all agree on, then I’d like to proceed on discussing benefits/drawbacks ratio of Oauth2 and PAT (and other techs if there is interest, like WebAuthn and MFA). To reiterate: I’m not opposed to Oauth2 (and I welcome work done by people to improve and and get rid of Oauth1); but I’m not really keen on the the idea that Oauth2 should be sole access method.
Again, I’m genuinely interested in what kinds of clients you all who are opposed to removing Basic Auth are writing. I would really appreciate it if you could write a short description (usecase, language, libraries used, environment, etc.) or post a link, that would help me (and everyone else) to understand your worries, or even help guide you to a solution.
This post is getting longish (understatement of the year 
), but since you ask again I’ll assume you’ve missed it earlier - as I’ve noted before (I’m not sure if in this thread or linked github one), most of my current use cases are simple oneliner wget | sed or similar scripts of small complexity (i.e. shell + wget/curl + grep / sed / awk + jq + xmlstarlet etc. - you get the idea). Quite often the bughunting for thing that broke, not some superb new idea that I’ve been the first on the planet to think of and written a script to do it.
The last one for example was trying to identify which of the obsolete OSM preferences introduced breakage when trying to PUT modified preferences back together (i.e. /api/0.6/user/preferences endpoint) for one of my accounts, but not other. Turns out it was preferences containing % sign put by Merkaartor app which I’ve used long time ago, which turned out to be the culprit when used with some Content-Type headers, but not others. I do not tend to save such one-time-use scripts on github for long term use, though (especially as they have hardcoded authentication tokens all over them). In hindsight, all bugs are shallow, but finding them was not trivial for me.
For more complex ones, I usually prefer to wget stuff from planet.osm.org and work with that (like my-notes or osm-torrent-related ones), although some do access api.osm.org instead (like osm-blame). But as even read-only API endpoints and even raw planet archives are increasingly likely to be auth-walled in some time in the future (search the OSM GDPR-related issues on github), so those usages might see sharp increase too.
And I hate when stuff breaks compatibility for no good reason, esp. if the stuff is not written by me, is no longer maintained upstream and is written in languages I do not really speak. (e.g. I’m more likely to just have to rewrite the whole thing in perl from scratch, than try to say learn Go and fix the issue in original code. Now if it was just changing URL to include PAT, it would obviously been significantly less painful and more time efficient)