Auth for third-party editors (iD MR-Fork, Rapid, JOSM) after API key removal – proposal for a token exchange
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 12/100
- Issue type
- Feature
- Clarity
- Needs clarification
- Activity status
- Active
- Tech stack
- scala
- Domain
- api, authentication
Research direction
This is a design proposal with no code location named, so start by reading the linked forum incident report and the two proposed options (access-token exchange versus OIDC ID token). The proposed endpoints are POST /auth/exchange and calls to the OSM API at /api/0.6/user/details and /api/0.6/permissions. Done means maintainers agree on one approach and the scope of the session token, which is a decision for the project, not a patch.
Written by the indexing model from the issue text.
Description
Thanks for the detailed incident report.
I'm working on a MapRoulette integration for iD at https://github.com/tordans/iD/pull/4 (browse tasks, edit, mark them fixed / not an issue / etc. from within the editor). Like standalone Rapid and the JOSM plugin, it used the API key from the OSM preference maproulette_apikey_v2, so task status updates now fail. The forum post says editor integrations will come back with "details still to be determined", so here is what the situation looks like from a browser-based editor and a proposal on how I think this could work.
Ideally I want a way from inside my iD-MR-Integration that Users can confirm for MR that they have a valid OSM Auth going. Or a way to create a handshake with MR directly.
Proposal: exchange an OSM token for a MapRoulette session token
Editors already hold an OSM OAuth2 token for the logged-in user. MapRoulette could accept it once and issue its own token:
POST /auth/exchangewithAuthorization: Bearer <OSM access token>.- MapRoulette verifies the token against
GET /api/0.6/user/detailsand checksGET /api/0.6/permissions, requiringwrite_api. - MapRoulette returns its own session token: random, short-lived, revocable, stored only as a hash. The OSM token is not stored.
- API requests accept
Authorization: Bearer <MapRoulette session token>as an alternative to the cookie.
Suggested limits:
- The session token only works for task actions (set status, comment, start/release), not for challenge or project administration, and never returns private user fields.
- We could go so far that users can see and revoke active editor sessions on their profile. Not sure if that is needed though…
- Optionally an allowlist of origins for the exchange endpoint.
Why I think this is safe enough: an application that holds an OSM token with write_api can already edit OpenStreetMap as that user, so being able to mark MapRoulette tasks as done adds little. Requiring write_api keeps out applications that only have e.g. read_prefs, which was the path in the second vulnerability of the report.
Stricter variant
If you want to control which applications may connect: accept an OSM OpenID Connect ID token instead of the access token. It is signed by OSM, carries the application's client ID in aud (so an allowlist of client IDs is possible), and grants no OSM permissions. The downside is that editors need to request the openid scope, which means a re-authorization for their users and a config change those Oauth Apps.
What are your thought on how to build this feature out?
- Dominant language
- Scala
- Stars
- 53
- Forks
- 39
- Avg merge
- 9h 24m
- Merged PRs (30d)
- 2
Getting set up
- Ships a Dockerfile or Docker Compose file
- No pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from maproulette/maproulette-backend
-
Difficulty 1/5 Under an hour Newbie friendliness 68/100
maproulette/maproulette-backend#1087 ·
-
Auth for scripts and CI after API key removal (personal access tokens) – tracking and use casesOpen
Difficulty 5/5 Over a week Newbie friendliness 8/100
maproulette/maproulette-backend#1288 · 3 comments ·
-
enhancement
Difficulty 4/5 3-5 days Newbie friendliness 45/100
maproulette/maproulette-backend#1258 · 1 comment ·
-
Difficulty 4/5 3-5 days Newbie friendliness 35/100
maproulette/maproulette-backend#1198 ·
-
Difficulty 3/5 1-2 days Newbie friendliness 42/100
maproulette/maproulette-backend#1192 · 3 comments ·
All issues in maproulette/maproulette-backend
Similar issues
-
area:scale audit priority:P2
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
KD5UJC-XYZ/scarab#231 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
SpinalHDL/VexiiRiscv#198 ·
Maintainers usually reply within 3 days
-
nativeLink relinks every build: IO.write leaves stale trailing bytes in build-checksumPossibly taken @kimmoeklund claimed this today. Open
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
scala-native/scala-native#5111 ·
Maintainers usually reply within 1 day
-
maintenance
Difficulty 2/5 1-3 hours Newbie friendliness 62/100
apex-dev-tools/apex-ls#603 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 67/100
Maintainers usually reply within 2 days