Hi, I want to point my HTTP integration to an API on either AWS or Azure, and I was wondering how to do that securely? Letting anyone call the API anytime they wanted would not be good. Where do I start?
Yes, I did. Still totally not sure what to do. Should I randomly generate an Authorization Header? And everyone’s gotta use that to use the API? Do I need to implement OAuth 2.0? Or should I take advantage of the pre-made IAM solutions in AWS? What’s the easiest way to secure the API calls? Thanks. 
Not randomly as it has a specific syntax; see my earlier answers.
Why everyone? I’d say: only the HTTP integration. Use other credentials (or even other ways of authentication) for other users.
No; that would need a dynamic value in an . The TTN integration only allows for a fixed value, so Basic Access Authentication Authorization: Bearer <token> headeror Digest Access Authentication are is probably easiest.
I don’t know those. Just a heads up from my other answers, when using that: some servers might validate the values in the Authorization header and not pass them if they do not follow the proper syntax or some might even try to validate the actual value. So if you don’t see the header and don’t know how to set up the server, then you’d need some of the other options from my earlier answers.
What do I put for the Authentication header? Like, what do I put for type and credentials?
Authorization: <type> <credentials>
See my answers and their links in the other topic.
I did. I don’t quite understand the answer, though. Could you please elaborate?
Really, just click the links. Basic Authentication is not something that’s only specific to the TTN HTTP integration.
That’s not quite accurate; OAuth could use long-lived tokens too. But if OAuth is not available it’s just easier to use something like Basic QWxhZGRpbjpPcGVuU2VzYW1l. Or when tempted to not even decode that on the server but just compare it to the expected value, you’d better avoid any confusion and use the custom header or URL parameters instead.
Okay, well for the time being, I’m using an AWS API Key to marshal API access. That just requires generating a key, and then adding a header of the form “x-api-key”: to the request. I’m thinking that because these motes’ interaction with the API would be short-lived, it would be simpler to skip token exchange altogether, and just use a static key. Curious to know your thoughts.
That works as well, by specifying a custom header when configuring the HTTP integration.
Also, we have launched the AWS IoT integration, so no more need for routing from the HTTP integration to AWS API Gateway and picking it up there.
1 Like
Nice! On AWS, I had an RDS instance on the “Free Tier” that was never used, and was charged $15 a month. Would love cheaper cloud solutions.
This integration may run for free in your AWS account, depending on what else you have running and on the number of messages.
The integration can run as a t2.micro instance (one is free per account) and smaller LoRaWAN deployments may fall well within the free tier limits of AWS IoT, see https://aws.amazon.com/iot-core/pricing/
1 Like
Though they claimed it was on the “Free” tier, my t2.micro was definitely not free.
Are you sure you were still in your first 12 months?
No, I am not still in the 12-month trial. “Free” just applies to the trial period?
RDS t2.micro is something different than EC2 t2.micro I guess. Anyway let’s get on topic again 
1 Like