Big problem - no. But an easily avoidable one for sure!
The core issue with using OAuth 2 for scripts is unnecessary complexity that is placed on the developers. So far, there is no sensible reason why we need to use OAuth 2.0 and can’t just use PATs. It feels like, instead of developing a solution once on the OpenStreetMap website, we will require each developer to write the same boilerplate code in each application, which seems like a waste. The idea of PATs is to handle this part on the server-side, transparently to the developer, achieving the same benefits of OAuth while centralizing the solution: easier for developers, more secure, and future-proofed.
The question is:
Why do we need to complicate script development? Is there a reason behind it? Or is it just an oversight?
Actually, it’s not**. There may well be places where PATs would be a good fit and the standard approach (usually SSO via an external IDP***) might be a bit heavy-handed, but Oauth 2.0 is the industry standard here.
** Based on the experience of my day job, which regularly involves helping customers negotiate this particular minefield.
*** and obviously a reliance on an external IDP wouldn’t work for OSM, though you can use one if you want.
@NorthCrab Perhaps this is an opportunity to take a step back and look at where we are:
You commented extensively on the github issue. Broadly speaking, no-one there shared your concerns**. You’ve now raised it in the Foundation area here, and many of the same people have also commented saying that they still don’t share your concerns.
At what point do you say to yourself “if I think A and everyone else things B, what information do I have that they do not, (or vice versa)?”. In this case a “collective delusion” or some sort of “conspiracy” among all the people who think that this Oauth2 change is a good idea seems unlikely, so the more likely explanation is that you are perhaps missing some of the knowledge or experience that led them to come to that conclusion?
Edit: There are at least two - TrickyFoxy below, and Mateusz in a diary comment … and 4 people have now liked the github post.
Hey! Can you please provide public API example that requires scripts to authenticate via OAuth? Also, yes, I did forward it to Foundation section to raise awareness of this change as it will directly affect the community. It’s fair to say that Operations’ GitHub is not the most active place for such a discussion. I never said it’s a conspiracy nor anything alike - I don’t know where you got that “quote” from. As previously stated, I believe it’s just an oversight.
Broadly speaking, no-one there shared your concerns
Please note that this untrue and it appears to me that your response is highly biased for some reason.
Oh, do we want only experienced developers to exceed the limits? Well, this summer and autumn we saw it.
Let me remind you that the OSM API is not limited to editing the map.
I absolutely agree with NorthCrab.
Let’s say you want to create a bot account. Or a client for forwarding incoming messages. Or parse user information (as far as I remember, not all information is provided by the API without authorization) Or. any other scripts…
Why is there an abstraction in the form of an OAuth application in these scenarios? These can be scripts in several lines of code for which [Login:Password]/token is more than enough.
And can I, as a developer, just copy and paste the token from the browser into the config of my script, leave it on the server and forget? Thank you, at least we have OAuth tokens with no expiration date…
To be clear, the first line of your first post in this thread was “I would like to express my concerns regarding OSM dropping support for Basic Auth”. To answer the question “who has dropped or is dropping support for basic authentication” a web search can easily provide a list. I’m in the UK and the results I see are heavily geared towards Microsoft and Exchange, but if I scroll down I also see Atlassian, Google, Jamf, Github and more.
You now seem to have moved away from wanting basic auth to stick around and now just just don’t want to have to implement Oauth2. In OSM, as elsewhere in the world, sometimes decisions will get made that make no sense to you. It might mean the decision was flawed, or it might just mean that you don’t understand why the decision was made. When this happens, generally speaking, we just need to “deal with it”.
The rate limits in question are for reading from the API and have nothing to do with the new upload rate limiting (being authenticated wont help you with the later). In normal use you are extremely unlikely to hit the limit, and relaxing it for authenticated users was added for the fairly narrow edge case of mapping parties when you have a larger group of people behind a single (NAT) IP address.
Currently only the private information of the authenticated user is restricted. That might change one day (not holding my breath) because the current situation is clearly not legal, but that applies to scrapping the API for user information in an automated fashion in any case -right now-, so not a use case that is going to win anybody over.
Since I can’t properly react, please join me in my living room for some popcorn while I pontificate in long-form prose. But don’t read the extif data off the image file and show up at my doorstep. That would just be weird.
Before I go on, I just want to clarify that you’re about to read the words of a complete moron who definitely qualifies as an unqualified developer. At least, as far as web authentication goes. My intelligence on other topics remains up for debate.
I’ve actually had to implement OAuth2 once, when I built StreetFerret, which authenticates with Strava. I stumbled through writing the code, and then once I got it working, promptly forgot how it worked and prayed that I’d never have to touch the code. So, I’m well-acquianted with being too dumb to implement OAuth2.
I actually think that even Basic Auth is too complicated for new and inexperienced developers.
Yikes! Even more gobbedlygook! I actually had to implement refresh tokens also for StreetFerret, and bear in mind that this was back in the days when you had to write shoddy code yourself rather than having AI chatbots do it for you.
This is also my approach to software development. But once in awhile the chatbot gets the code right.
Thrown shade right there, but maybe you’re onto something?
Total oversight, and I’ve got the solution.
I agree with @NorthCrab that we should eliminate OAuth2 for easier scripting, and I agree with @pnorman that we should eliminate OAuth 1.0 and Basic Auth. And, I agree with @02JanDal that we should reinvent the wheel, which we are so good at as noted.
I propose SIMPLE web authentication, which stands for Super Insecure, Moron-Proof Login Experience.
The way it works is very simple, you just add your username and password into the querystring of any authenticated request you want to make to openstreetmap.org.
For example, a login request might look like this:
So simple, even a moron could figure out how to curl some sweet, sweet API write requests. It’s also perfectly secure since we’re using HTTPS. To be really user-friendly though, we should consider implementing this functionality on plain-old HTTP as well.
I stand with @NorthCrab in protesting the needless complexity of modern, secure authentication protocols and yearn for a simpler time when passwords were just the names of our pets, and the most advanced hacking tool was a sticky note left under a keyboard1.
Hear hear!
Pass the .
I expect a long-form response to my very serious proposal.
1pretty solid punchline for an AI chatbot I think.
You didn’t get the hint. I mean, the barrier in the form of inconvenient authorization is the wrong protection against misuse of the API. For Example, this did not save us from automatic vandalism in Russia and Israel. We shouldn’t scare off conscientious developers at the very beginning.
This is not an excuse for inconvenient authorization.
It is sad. But it still doesn’t mean that we are limited to just editing the map.
@NorthCrab is making the argument that not supporting basic auth creates a significant hurdle to using the API. I’m just questioning his statement that that is somehow bad because it stops “New and inexperienced developers”.
Being serious, you’d have to have been living under a rock to have avoid being bombarded with stuff about passkeys (as WebAuthn is also known) in recent weeks. The problem is that while it is a solution to a common problem, I don’t think that it would help with scripted API access, which seems to be the main issue above.
Having said that, the only scripts that I do use against the OSM API already do support Oauth2, so I don’t see a problem…
I’ve been developing software for almost 30 years now, and there are - obviously - still concepts/languages/… that I have no experience in. I had to learn tons about OSM in the last decade, and I am guessing that there are more people out there like me who have to actually learn how something works rather than just knowing it by the grace of the FSM.
Given the Etiquette/Etiquette Guidelines - OpenStreetMap Wiki from 2022 explictly state “Be welcoming. OpenStreetMap aims to be a community that welcomes and supports people of all backgrounds, cultures and identities. […] Remember that people may be new to OpenStreetMap. We should be tolerant and supportive towards new members.”, you questioning how “stopping new developers” is somehow bad, for me, just doesn’t fit.
If you want to prevent new developers from screwing up the live database (costly vandalism that doesn’t care about anything OSM stands for, aside), IMHO, there’d need to be a system for checks on what API users are doing, that’s far more than just using a secure Authentication Mechanism.
If the only concern for scrapping BA is password safety (as hinted to by @pnorman in his diary entry) than this whole discussion becomes user-centric (Does OSM trust their users to use secure passwords and not the same for every account? Does the user maybe want to use BA rather than re-issuing OA1 tokens every x months?) and the experience and capabilities of the developer have nothing to do with anything.
In hindsight, judging a support for an idea after giving a post mere 5 hours on Sunday evening (or night, depending on your TZ) was bound to to produce, ah, somewhat suboptimally representative statistical sample
I was talking about this thread on discourse (where your claim of “no support” was written)… Not much regular people follow all OSM github issues or random OSM diaries. While I would guess I follow way more OSM random discussions on several mediums (including GitHub) than the average Joe, even for me this thread was first sight of the issues @NorthCrab raised awareness of.
That’s funny that you think it’s the technology that’s the biggest barrier to (checks notes) new, inexperienced developers. In my experience, the more common complaints are about the people that maintain the software packages involved not…how can I put this nicely…fostering the sense of community that would facilitate an optimal onboarding of a new developer. Of course, we could make the same argument about openstreetmap-ng, which doesn’t even pretend to be a community effort.
)
