OAuth 1.0a and HTTP Basic Auth shutdown - General talk - OpenStreetMap Community Forum

OAuth 1.0a and HTTP Basic Auth shutdown - General talk - OpenStreetMap Community Forum
OAuth 1.0a and HTTP Basic Auth shutdown
General talk
api
editors
development
pnorman
(Paul Norman)
January 26, 2024, 1:54am
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.
9 Likes
Josm fails to authenticate with OSM server
No josm-authorisation from osm-server
Adresseimport fra autoAWS er nede disse dage
Osm tracker unable to authenticate
Mise à jour des cartes
Anmeldung auf "osmand+"
westnordost
(Westnordost)
January 26, 2024, 10:34am
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.
2 Likes
TomH
(Tom Hughes)
January 26, 2024, 11:14am
westnordost:
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:
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.
westnordost:
Additionally, access tokens on OSM have no expiry date and thus no refresh tokens are handed out.
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.
4 Likes
SekeRob
January 26, 2024, 11:48am
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
pnorman
(Paul Norman)
January 26, 2024, 11:52am
The OAuth site has a good section on
access token lifetime
. Their recommendations are
use short-lived access tokens and long-lived refresh tokens when:
you want to use self-encoded access tokens
you want to limit the risk of leaked access tokens
you will be providing SDKs that can handle the refresh logic transparently to developers
use short-lived access tokens with no refresh tokens when:
you want to the most protection against the risk of leaked access tokens
you want to force users to be aware of third-party access they are granting
you don’t want third-party apps to have offline access to users’ data
use non-expiring access tokens when:
you have a mechanism to
revoke access tokens
arbitrarily
you don’t have a huge risk if tokens are leaked
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.
2 Likes
TomH
(Tom Hughes)
January 26, 2024, 12:04pm
SekeRob:
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?
Yes the OAuth 2 implementation merges multiple authorizations into one and allows them all to be revoked in one go.
3 Likes
ZeLonewolf
(Brian M Sperlongano)
January 26, 2024, 1:49pm
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.
1 Like
02JanDal
(Jan Dalheimer)
January 26, 2024, 2:11pm
Yes and no.
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.
2 Likes
SimonPoole
(Simon Poole)
January 26, 2024, 5:25pm
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”.
1 Like
Taktaal
January 26, 2024, 10:31pm
10
Or do it like some services do where they have non-expiring tokens, but manually expire all tokens when the user changes their password.
1 Like
NorthCrab
January 27, 2024, 6:04am
11
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
pnorman
(Paul Norman)
January 27, 2024, 6:47am
12
NorthCrab:
Are there any plans to deprecate OAuth 1.0 (not 1.0a)?
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
NorthCrab
January 27, 2024, 7:05am
13
openstreetmap/openstreetmap-website/blob/67669171af7e088d19378913cbd37f9cab98ea5b/config/settings.yml#L99
attachments_dir: ":rails_root/public/attachments"
# Log file to use
#log_path: ""
# Log file to use for logstash
#logstash_path: ""
# List of memcache servers to use for caching
#memcache_servers: []
# Enable HTTP basic authentication support
basic_auth_support: true
# Enable legacy OAuth 1.0 support
oauth_10_support: true
# URL of Nominatim instance to use for geocoding
nominatim_url: "https://nominatim.openstreetmap.org/"
# Default editor
default_editor: "id"
# OAuth application for the web site
#oauth_application: ""
# OAuth application for iD
#id_application: ""
# Imagery to return in capabilities as blacklisted
imagery_blacklist: []
openstreetmap/openstreetmap-website/blob/67669171af7e088d19378913cbd37f9cab98ea5b/app/models/request_token.rb#L80
else
"#{super}&oauth_callback_confirmed=true"
end
end
def oob?
callback_url.nil? || callback_url.casecmp("oob").zero?
end
def oauth10?
Settings.key?(:oauth_10_support) && Settings.oauth_10_support && callback_url.blank?
end
end
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.
2 Likes
pnorman
(Paul Norman)
January 27, 2024, 7:07am
14
I thought it had been, but you’d have to (nicely) ask the website maintainers to be sure.
NorthCrab
January 27, 2024, 7:19am
15
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
).
Matija_Nalis
(Matija Nalis)
February 11, 2024, 10:21pm
16
NorthCrab:
I have just confirmed that OAuth 1.0 is still enabled on the OpenStreetMap website
From
[Announce] Removing OAuth 1.0a and HTTP Basic Auth - 1st June 2024
PS: OAuth 1.0 (not 1.0a) was previously erroneously enabled, but has now been disabled.
Firefishy
(Firefishy)
May 28, 2024, 10:46am
17
We have now started brownouts of HTTP Basic Authentication and OAuth 1.0a support. For periods of a few hours
OpenStreetMap.org
may not accept HTTP Basic Authentication and OAuth 1.0a and will provide an error which points at
2024 authentication update - OpenStreetMap Wiki
The brownouts are an attempt by us to flag to developers about the upcoming demise of HTTP Basic Authentication and OAuth 1.0a authentication methods.
6 Likes
Matija_Nalis
(Matija Nalis)
May 28, 2024, 1:01pm
18
Firefishy:
For periods of a few hours
OpenStreetMap.org
may not accept HTTP Basic Authentication and OAuth 1.0a
How many is “few hours”, though?
I’ve got
"OAuth error 401 at stage "create": Couldn't authenticate you."
trying to edit with Level0
day and a half ago (on May 26 2024 at 22:15 CEST), and it still returns same error yesterday (at some unidentified times) and today (May 28 2024 at 14:47 CEST).
It might be that I’m just extremely unlucky and every time I try I hit the brownout period, or it could be something else (bug in reenabling?)
Any more information on the schedule when I can try to upload my pending changes lest they be lost? Can you share
@Firefishy
at what periods of following days before June 1st will Outh1.0a be still allowed?
2 Likes
TomH
(Tom Hughes)
May 28, 2024, 1:21pm
20
We’ve only done one so far and that was between about 08:00 and 10:00 UTC on the 27th.
There will be another one around 1300 UTC tomorrow, and then around 1800 UTC on Friday.
2 Likes
Matija_Nalis
(Matija Nalis)
May 28, 2024, 3:50pm
21
TomH:
We’ve only done one so far and that was between about 08:00 and 10:00 UTC on the 27th.
Thanks for the information.
Since
Level0
still showed problems at May 28 17:44 CEST for me, I’ve removed its Oauth1 entry in my settings, logged out and back in again, and now it works again at May 28 17:47 CEST.
(Why it didn’t auto-recover after brownout despite multiple force-refreshes, I have no idea, but maybe the procedure will help others.)
next page →