CODEWITHSUNDEEP
restapi-key
smashbourne
smashbourne

Reputation: 463

API Key in path

We have some IoT sensors that POST json payloads to an endpoint. They are configured with only a HTTPS URL to send to, no ability to setup authentication etc.

We need basic ability to see which sensor is sending data, and loosely prevent anyone from sending payloads. Full authentication will not be possible.

It was suggested we could put a token in the path and use it as a super basic API Key. I was wondering what the best format for the route should be...

/api/events/_ingest/api-key

/api/producer/api-key/events/_ingest

Upvotes: -1

Views: 1820

Answers (3)

Jeremy Fiel
Jeremy Fiel

Reputation: 3307

For backwards compatibility, using a query param would allow you to support an authentication header in the future on the same service. Then you can accept both query param or header to authenticate your devices enabling both old and new devices the ability to use the same url.

POST /api/v1/events?api-key=123456 HTTP/1.1
content-type: application/json; charset=utf8
authorization: bearer{api-key}

{ "events":[{...}]}

---
201 Created HTTP/1.1

Not sure what the ingest signifies but it seems unnecessary; posting to a collection of events seems the most reasonable solution

Then you can query by event if that's something you want to provide

GET /api/v1/events/{event-id} HTTP/1.1
accept: application/json

---
200 OK HTTP/1.1
{...}

Upvotes: 0

pointyhat
pointyhat

Reputation: 596

Disagree with the accepted answer. While it is common wisdom that "an api key goes in a header", passing the key in the url doesn't summarily translate to really bad.

Believe the main risk is leaking of the key through browser history, or via http logs, on internet devices along the traffic route. Neither seems relevant in the above case: OP describes a M2M https POST api. So there's likely no browser involved, and even if there is, it would not record a POST in history. Since it's an https api, the url path is encrypted along with traffic. So, given the context, don't see header as more secure than the url path.

To answer the OP's question: Would go with /api/producer/api-key/events/_ingest. Mostly bc it suggests easier api client management: a single url per-client (can quickly be removed, if you suspect a breach).

Upvotes: -1

cassiomolin
cassiomolin

Reputation: 131147

I was wondering what the best format for the route should be: /api/events/_ingest/api-key or /api/producer/api-key/events/_ingest

There's no best approach here, both are really bad. The API key does not belong to the URL. It should be sent in the standard Authorization HTTP header.

Once you mentioned in the comments that it will be something temporary, you could try a query parameter. It's still bad though. But you will be able to reuse this same route later, just moving the API key to a HTTP header, when your clients support it:

/api/events/_ingest?api-key=somecoolhashgoeshere

Upvotes: 2

Related Questions