Yes, if someone would, in good faith, ask me to help migrating away from Basic Auth I would do so (as I’ve previously mentioned, provided it’s in a language/framework I’m familiar with), because I’m not someone who just complains (or responds to complaints), though I won’t take on any long term maintenance responsibilities (sure, 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).
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.
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. A good library interface would look like this, note how it does not require any knowledge of OAuth more than that you’ll have to copy two strings from the OSM website.
I second what @pnorman wrote; a good programmer would never write their own OAuth 2 library (though it is a fun exercise if you want to spend time on that, just don’t try to write your own OAuth 2 server implementation (just like you shouldn’t write your own password hashing function)). A good software engineer knows which parts to implement themselves and which to take of-the-shelf.
Now this statement is once again straight out wrong, because OAuth 2 does provide extra security over Basic Auth, some of which have already been mentioned in this thread, some even in your own post.
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. Sure, OAuth 2 has drawbacks, but they are over-weighted by the benefits.
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.
I appreciate hearing (again, not learning it) that vinegar catches flies, too. (Apple cider vinegar is said to be especially effective). Speaking plainly, instead of an idiom that means “it is easier to persuade others with polite requests and a positive attitude rather than with demands, negativity and even rudeness” I’ll say (plainly and simply) “it is easier to persuade others with polite requests and a positive attitude rather than with demands, negativity and even rudeness.”
actually DOES tell me that there is some “tongue in cheek” or “some kidding going on here” attitude, but such mistakes are easy to make. It can be helpful in this forum to be direct, polite, helpful, make criticism constructive if possible, et cetera. We all know that doesn’t always happen, but most of us really do prefer honey to vinegar. Really, we do.
Now, back to our regularly scheduled programming. (A bit sweeter, we might expect).
Edit and Postscript; Timestamps are (and have been) a good idea with authorization. To remove that feature seems retrograde to me and I think many might like to see it return.
To be fair, that’s part and parcel of working with OSM. Requirements change. Moving to multipolygons-on-relations* was a whole bunch of code and head-scratching for editors to implement, but it got done.
If I were to compare the impact of that on two of my projects, I find it’s more work to keep cycle.travel in sync with the latest wiki-fuelled tag insanity, than it is to update Potlatch for things like multipolygons-on-relations and OAuth 2.
* Multipolygon relations are still a stupid idea because relations are metadata and multipolygons are geometry, but I digress. (At least until we get a popcorn emoji.)
Note that I was asking for why it is being removed, and I am not protesting against removal. Though I am also not entirely convinced that it is worth it and I am not a great fan of stuff being deprecated (though it is hard to find people liking that stuff they use got deprecated).
On the other hand if maintainers of website (and therefore ones that would be getting complaints if something goes wrong), and ones who handle it really well, think that it should be done then I am not planning to campaign against such move. Especially as I made almost no contributions to osm website and I do not know well its internal architecture.
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)
I’m well aware of his work (indeed I’ve been quite active in his other threads, including having the first reply in the thread you linked to). And while I think his work is admirable, I think he is approaching it wrong (doing the technical before community), and though I wouldn’t mind being disproven I believe the likelihood of his project replacing the current OSM backend stack is next-to-none.
Now, if his project does get deployed alongside the Ruby port (or even eventually replaces it) I would be happy to see it support PATs. But he has (unless I missed it) never offered to do that work for anything else than his own private project (and just to be clear; he of course has no obligation to do so either).
Please point me to the place I’ve said that we should use an overly complex solution without reason so that I can highlight clearly that I miswrote that.
OAuth 2 is reasonable complex yes, and while there certainly are some parts of it that could have been made a little simpler, most of it is done as it is for a very good reason.
I’d love for us to live in a world were we can login with just our username and nothing else for the minimal amount of complexity, but sadly that’s not the world we live in.
But the access security is different. With your OAuth token (or PAT), I can at most edit data on behalf of you, handle notes on behalf of you, change your preferences, upload and read GPX traces on behalf of you, and publish diary entries in your name (and that’s only if the app those token was stolen got access to all that, most clients don’t (need to) request all possible permissions). I cannot, however, change (or even see) your email or password (possibly locking you out of your account), delete your account, etc.
And there we’re back to why Basic Auth is such a bad idea and should be removed: There is no decent way to solve that problem; once an attacker has your username+password they’re in (and not only in OSM, since most users have bad password hygine). (MFA would help, but it’s only a bandage, not a solution)
That’s fine, especially since so far no one has argued against that point (I have argued that having to use OAuth isn’t as bad as some have made it out to be and against people almost requiring PATs be implemented by unpaid volunteers, and others similarly)!
OK, I’ll ask tomhughes through GitHub if he can ignore an ugly v1 UI for a moment and imagine being able to get the atime of an inode. If being able to have that (the access time) of a timestamp (as part of an authentication protocol) doesn’t help, mmm, I think it could. It’s a deep rabbit hole of misplaced trust if it goes sideways, though that is a concern with the design of any good authentication protocol. But let’s not invent anything new, I’m imagining a potentially useful scenario where, yes, I think, there IS a “last used timestamp.” It is not stored “anywhere,” it is deep in the bowels of the OS as the inode’s atime, if I am not mistaken. What could have OAuth 2.0 done with this? Something, for sure, but it remains unknown to me what that is. Nothing, probably. Though, something, possibly.
The rest of the topic’s participants, kindly bubble back up as I pop this stack. Return.
True (never needed to even try looking for it in the documentation, weirdly), though there is an OAuth scope for it. Probably there were some plans for that which never got materialized.
For the sake of eliminating spam and vandalism, It’s a relatively small price to pay.
Several months ago, we experienced a significant vandalism event. Finding all the specific rogue modifications without removing any legitimate contribution was nerve-breaking, and we’re not even sure we’ve completely recovered from it.
While I definitely agree with that suggestion (who wouldn’t? Except vandals themselves), I fail to see how it is related to this discussion about replacing Basic Auth with OAuth2 ?
As I see it, the issue with vandalism is completely the same regardless if vandal is using Basic auth or OAuth2 bearer token in their script? It is literally single line change. Or am I missing something?
Regarding vandalism and limits, rather see / chime in this topic (and others linked to it):
I’ll second that vandalism isn’t directly related to the authentication mechanism, though there are two points relating to the vandalism that’s been that I think are relevant here:
It (the vandalism) has shown very clearly that OSM is a target for (dis)information campaigns, and though this wasn’t the case yet (I hope) it’s not inconceivable that there might more sophisticated “attacks”, possibly even performed by state-level actors
Rate-limits seem to have helped quite a bit, but it is likely that the vandals will seek ways to circumvent them; one possible approach is stealing login details from OSM users with enough edits that they will not be rate-limited as much as a new account
In fact, if I wanted to get my hands on login information from OSM users (and other than buying leaked dumps from other systems and hoping that someone re-uses their password), I would provide a OSM-related service that enough people are interested enough in to give it a try, but that uses Basic Auth for authentication. While a similar thing can be done using OAuth it is a lot easier to shut down (just mass revoke all granted tokens for that specific client).
Let’s go. I’m not a Ruby developer or a frontend developer. But still, here is the MVP of the browser extension, which will show how the process of obtaining an OAuth token should look like
But I don’t think that your comment was fair to 
), 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 
