The Operations Working Group is shutting down OAuth 1.0a and HTTP Basic Auth in 2024. They have been deprecated since 2023 and their role in authorization has replaced by OAuth 2.0 which the standard authorization method for most systems. This change will have three key dates:
March 1st, 2024: New OAuth 1.0a application registrations are disabled. Existing applications will not be impacted. HTTP Basic Auth will not be impacted.
May 1st, 2024: Sysadmins will start brownouts to find applications that are still using OAuth 1.0a or HTTP Basic Auth
June 1st, 2024: OAuth 1.0a and HTTP Basic Auth will be shut down.
This change is necessary because of the complexity of maintaining so many authorization implementations including ones that rely on unmaintained components and because of security concerns.
What does this mean to me, as a non-technical person?
Most mappers will notice no change. This will not change how you log in to your OSM account or how you use the website. iD and JOSM have supported OAuth 2.0 for some time as the default. If you use your OSM account to log on to a third-party site like the HOT Tasking Manager, MapRoulette, or HDYC you will not be affected as those sites have already moved to OAuth 2.0. Read-only API access does not require authorization at all.
I’m a developer, what do I need to change?
If you are a developer, you might need to make some changes, but OAuth 2 is an industry standard and well-supported.
If your application only makes read calls to the API authorization is optional. It can still be a good idea for rate-limiting reasons to add authorization to your requests, but it is not required. If your application is a website using OSM for logins, OAuth 2.0 is much easier as it is much better supported because so many other sites use it. It also avoids problems like users ending up with many tokens in their list on the website.
If you are developing software that edits using the API and is run locally you may need to make code changes. All common languages have libraries that deal with OAuth 2 and libraries are the preferred choice for any authorization. If you decide not to use a library, there are multiple options you can choose. Zverik wrote a library for command-line tools that can handle authorization, or if you want to do it completely yourself it can be done in about a dozen lines of shell script.
You should be able to find lots of examples of OAuth 2 client implementations in your language by searching online. If you want technical details on the change there is a ticket on github. Please take any technical concerns there.
FYI OAuth 2.0 is a huge specification. Amongst others, it also allows access through username + password.
This part of the standard is however not supported by OpenStreetMap. In fact, only and exclusively the authorization method described in section 4.1 is supported:
Additionally, access tokens on OSM have no expiry date and thus no refresh tokens are handed out.
There is a soft guarantee that this will not change, as most/all OSM client implementations rely on tokens having no expiry date now (except JOSM).
Hence, to change this would require prior notice and a campaign like we are seeing now for the migration to OAuth 2.0.
We are unlikely ever to enable that because the whole point of getting people to use OAuth is to stop them sharing their password with third parties - we want them to be providing that only to us by going through the authentication code flow.
I’ve actually been looking at this a bit over the last few days and while there are uses for refresh tokens especially when the server does not track access tokens (so they can’t be revoked) there is considerable debate about whether they serve any useful purpose in other cases.
We do track access tokens and allow them to be revoked, so the advantage of being able to revoke refresh tokens when you can’t revoke access tokens does not apply to us.
Is this transition going to mean I wont be sitting with reams and reams of open auths on the “My OAuth Details” page any longer? Occasionally I would go in and revoke them all and then of course find the last time logged gets binned too and some editor asking me to log in again. Now it shows top of list last time on a 2 page tally was Jan 3 for Osmose. In amongst on there are oldies for Kartaview, JOSM and HDYC
you want to provide an easy authentication mechanism to your developers
you want third-party applications to have offline access to users’ data
Short-lived access tokens are great if you need to do auth control on a service that can’t communicate with another server to check if the token is valid, because they can be self-signed. This could be a good option for a tile CDN if we were unable to store valid apikeys on the CDN.
Regard refresh tokens, I thought the reason they were useful was to prevent someone from obtaining a “forever token” and then sharing it or storing it somewhere insecure. Basically, the same issue already noted about not wanting people to share passwords around. By forcing the end-user application to repeatedly request refresh tokens, you block password sharing, which is generally regarded as a good thing I think.
Since a refresh token (together with client ID and client secret) gives you an access token and a new refresh token, the same issue happens if someone steals your refresh token (if they also get access to the client ID and secret, which are out in the open in most editors because there’s no good way to protect them). They can then just forever refresh it.
There is some value in that an old (refresh) token found won’t help you, so if tokens must be refreshed say every 30 days then as long as you use the software (editor or whatever) at least once in every 30 day period then you won’t have to log in again, but an attacker finding a token on an old drive or something won’t be able to use it (provided it is older than 30 days). Question is if there really are attackers that are so determined to get into OSM accounts to so that they’ll spend time on combing through old backups and stuff.
I kind of would prefer to simply expire the access token after a suitably long period (for example a year) forcing the user to re-authorize the app (and generate a new token).
The luxurious variant would be for the app in question to nag the user to re-authorize before the token has expired to avoid “it expired just when I was on a road trip and I couldn’t remember the password”.
Are there any plans to deprecate OAuth 1.0 (not 1.0a)? To my knowledge, both are officially supported by the OpenStreetMap website, but all announcements seem to only mention 1.0a. Perhaps an oversight? To me, it doesn’t make much sense to deprecate 1.0a with 1.0, as big chunks of code are shared between those two versions .
OpenStreetMap currently supports OAuth 1.0a and OAuth 2.0. OAuth 1.0 has known security exploits which were fixed in OAuth 1.0a which was released in 2009. OAuth 1.0a was then, in turn, obsceleted by OAuth 2.0 in 2012.
I haven’t studied OAuth 2.1 but my understanding is it is largely a codification of best practices and well-established extensions. We’ve already got stuff like OAuth discovery.
From the application source code, it looks like OAuth 1.0 (legacy oauth) is enabled. A few weeks back, I was also able to authorize with OAuth 1.0 (not 1.0a). The oauth10? method is used to distinguish between OAuth 1.0 and OAuth 1.0a versions. It seems like OAuth 1.0 was never deprecated by the OpenStreetMap website. Ideally, it should be done alongside OAuth 1.0a deprecation.
I have just confirmed that OAuth 1.0 is still enabled on the OpenStreetMap website by following the non-1.0a authorization flow. The final response did not include the verifier token (that is only present in 1.0a).
.