En 2024, le groupe de travail OSMF Operations Working Group (OWG) retire OAuth 1.0a et HTTP Basic Auth sur OpenStreetMap.org. Il s’agit de moyens techniques permettant aux applications d’authentifier les utilisateurs auprès du site web OSM ou de l’API. OAuth 1.0a et HTTP Basic Auth sont obsolètes depuis 2023, car OAuth 2.0 est désormais la méthode d’autorisation standard pour la plupart des systèmes.
Il y a trois dates clés dans le processus de transition :
- 1er mars 2024 : les nouveaux enregistrements d’applications OAuth 1.0a ont été désactivés. Les applications existantes n’ont pas été affectées. L’authentification de base HTTP n’a pas été affectée.
- 1er mai 2024 : les administrateurs de système commenceront à faire des recherches pour trouver les applications qui utilisent encore OAuth 1.0a ou HTTP Basic Auth.
- 1er juin 2024 : OAuth 1.0a et HTTP Basic Auth seront supprimés.
La suppression de ces méthodes d’authentification est nécessaire pour des raisons de sécurité et en raison de la complexité de la maintenance d’un si grand nombre d’implémentations d’autorisation, y compris celles qui reposent sur des composants non maintenus.
Quel est l’impact pour moi en tant que développeur ?
Si vous êtes développeur d’une application utilisant OAuth 1.0a ou HTTP Basic Auth pour vous connecter au site OpenStreetMap.org, vous devrez peut-être effectuer quelques changements pour passer à OAuth 2.0. Heureusement, il s’agit là d’un standard qui est largement soutenu.
Si votre application n’effectue que des appels en lecture à l’API, l’autorisation est facultative. Pour des raisons de limitation du débit, il est toujours souhaitable d’ajouter une autorisation à vos demandes, mais ce n’est pas obligatoire. Si votre application est un site web utilisant OSM pour les connexions, il est beaucoup plus facile d’utiliser OAuth 2.0, qui est beaucoup mieux pris en charge parce que de nombreux autres sites l’utilisent. Cela permet également d’éviter les problèmes liés au fait que les utilisateurs se retrouvent avec de nombreux jetons dans leur liste sur le site web.
Si vous développez un logiciel qui édite à l’aide de l’API et qui est exécuté localement, il se peut que vous deviez modifier du code. Tous les langages courants disposent de bibliothèques qui gèrent OAuth 2, et les bibliothèques sont le meilleur choix pour toute autorisation. Vous pouvez également utiliser la bibliothèque d’outils de ligne de commande de Zverik ou écrire votre propre script shell d’une douzaine de lignes.
Vous devriez pouvoir trouver en ligne de nombreux exemples d’implémentations de clients OAuth 2 dans votre langue. Si vous souhaitez obtenir des informations plus détaillées ou poser des questions techniques, veuillez utiliser le ticket GitHub. Ici, l’OWG suit également les applications nécessitant une modification pour utiliser OAuth 2.0.
Quel est l’impact pour moi en tant que cartographe ?
La plupart des cartographes ne remarqueront aucun changement. La transition n’affectera pas la façon dont vous vous connectez à votre compte OSM ou dont vous utilisez le site web. L’iD et le JOSM supportent OAuth 2.0 comme méthode d’authentification par défaut depuis un certain temps. Si vous utilisez votre compte OSM pour vous connecter à un site tiers tel que HOT Tasking Manager, MapRoulette ou HDYC, vous ne serez pas affecté, car ces sites sont déjà passés à OAuth 2.0. L’accès à l’API en lecture seule ne nécessite aucune autorisation.
This post is also available in: Anglais Japonais Espagnol Grec moderne Arabe
