Authentication using API keys

[ricardobalk]

While testing the location tracker with a simple nginx reverse proxy set-up, I found out that the OsmAnd does not support Basic Authentication nor Digest Authentication. Bummer. However, TLS/SSL works. 👍

So, instead of using Basic Authentication, authentication with API keys would be a good alternative.

As TLS/SSL has been added (#44), the key can be added to the query parameters of a GET request (GET /submit?api_key=...). If used with TLS/SSL, it won't compromise the security. Only thing is that the server, when started in debug mode, might show the full URL with this "sensitive" data. Still, considering the server runs in a production environment, this is fine.

An even better way of sending an API key via a GET request would be by using a cookie or request header, like X-API-KEY: ..., so there won't be a URL containing an API key written to the log files. However, setting cookies or request headers not possible with OsmAnd.

[ricardobalk]

This one is on me. Will see what I can create.

[moogacs]

Would you merge #13 ! And I agree with you that it would be better if it's in the request body instead of the URL

[denysvitali]

I'm curious to see what's your idea for this topic: I see different options that might be explored, depending on the project goals / use cases.

One publisher, few listeners

Use cases

• Location sharing with your friends

This is a situation where you basically have one publisher and N listeners, with N usually < 10.

Security

In this case, the endpoints must be secured as follows:

• One key for the publisher (so that only he can push location changes)
• One key for the listeners (so that only people with the key can see the shared location, for X minutes)

Single location broadcast

For certain situations, it might make sense to broadcast the location of an object / person.
This is a one to many approach, and ideally the clients do not need to authenticate themselves to see the location because the information shall be public.

Use cases

• Public transport location broadcasting
• Position of a cyclist in a race

Security

• One key for the publisher (so that only he can push location changes)
• No key for the listeners - the location is broadcasted and everyone should be able to see this position

Many publishers, few listeners

Certain use-cases might need different publishers to send their location to a centralized place.

Use cases

• Group of friends at an event, sharing their position in real-time
• N users approaching the same location and wanting to share their ETAs

Security

• Multiple keys for publishing, but each key must be able to update only one position
• N listeners that are able to view the location on the map

Many publishers, many listeners

This is the most complex use case: in certain situations you might want to broadcast the position of many objects / people in real time, and let this be visible by a lot of people.

Use cases

• A race, where every publisher is a participant and every listener is a spectator
• A ride-sharing app, where the users can see every (free) driver location on the map

This approach requires a better handling of the locations in the database, ideally with a Geo Spatial database such as PostGIS, so that only the locations in a certain bounding box / in a radius from the user's location are returned.

Security

• Multiple keys for publishing, but each key must be able to update only one position
• No key for the listeners - the location is broadcasted and everyone should be able to see this position