Använda API-nycklar i appar på ett säkert sätt?

Låt oss säga att jag vill använda en vädertjänst för att skapa en väder-app. Man kan köpa ett antal anrop per månad för en viss summa. Man får en API-nyckel för att kunna göra anropen.

Appen måste då använda sig av denna API-nyckel för att kunna hämta datan. Hur hindrar man då att någon stjäl API-nyckeln? Går ju göra allt från att dekompilera appen, eller använda andra verktyg för att plocka ut strängar från appar. Man kan t.ex. använda https i anropen för att hindra sniffing, men det hjälper ju fortfarande inte på API-nyckeln finns hårdkodad som en sträng i appen. Även om man försöker lagra API-nyckeln i någon typ av krypterad form så går det som sagt analysera appens funktion för att rekonstruera hur nyckeln dekrypteras.

Enda sättet jag kan tänka mig är att sätta upp en egen proxy-server dit anropen sker. API-nyckeln ligger skyddad på denna server och anropen från mobilklienterna sker till proxyservern. Detta känns dock onödigt då man dessutom får driftkostnader för en server som ska hantera allt detta, istället för att appen går direkt till API:t.

Att köra det molnbaserat är en lösning. Annars kan du ha ett hardlock usb, typ codemeter som skydd. Där är mjukvaran skyddad dels genom kryptering men även integrity checks om någon ändrar något.

Är tjänsten för konsumenter? Vad handlar det om för pengar för kunden?

Jag vet ännu inte. Är inte så konkret än, funderade mest på hur man löser det. Tanken är ju att appen ska vara till helt vanliga konsumenter. Jag tänker kanske inte att vanliga användarna själva plockar ut API-nyckeln och gör tiotusentals anrop per dag, utan mer att någon skygg utvecklare i Kina stjäl den och använder i sin egen app, och får på så vis gratis tillgång till API:t åt sina användare - på den som äger API-nyckelns bekostnad.

Brukar läsa in API-nycklar som miljövariabler ifrån där jag hostar koden.

Det här låter inte så genomtänkt. Hade du tänkt skeppa ut en app som har en API-nyckel i sig, där du har ett antal anrop per månad? Du har ju då ingen som helst kontroll på skeendet och har bara tur om inte antalet anrop slår i taket?

Varför sätter du inte upp en egen backend-tjänst som kommunicerar med API:n?
Du har då din egen autentisering för att klientsidan (apparna) kommunicerar med din backend.
Din backend har API-nyckeln och kommunicerar med väderappen och skickar vidare precis den data som behövs till klientsidan.
Kanske cachar du även API-datan på din backend, för att hålla nere antalet anrop?

Säger detsamma, secrets (databasanslutningar, api-nycklar till tredjepartsapier etc) brukar man ju normalt ALDRIG skicka ut utan det får en backendservice ta hand om, så får appen anropa denna service som i sin tur skickar vidare anropen.

Finns ju en annan aspekt av det hela med och det är ju om det data från apiet inte är riktigt bra för din app (till exempel om det skickar ut irrelevant data) så kan du ju alltid packa om det till nåt som är bättre lämpat för din app med om du har en egen backend som sköter om det.

Som sagt, secrets heter secrets av en anledning.

Ja det är en av idéerna jag haft, speciellt cacha data för att minimera anropen och kostnaden. Frågan är hur man ska komma ifrån att användaren måste registrera sig för att använda en app. Många inklusive jag själv är väldigt skeptiska till att behöva registrera sig för att få använda en app. Jag tror inte jag har använt en enda väderapp där man måste registrera sig först innan man kan använda den. Nu är väder-app bara ett exempel, men det finns många app-idéer jag har som behöver använda api-nycklar.

Varför ska man behöva registrera sig för att använda en väderapp?

Ja det var min fråga också. Förut kunde man använda sig av ett id som var unikt för enheten, men detta är inte längre tillgängligt (gäller iPhone, Android kanske fortfarande har den möjligheten).

Ja det är så det ska göras, t.ex. Python så har du API nyckeln i .env fil som du sedan hämtar in i din kod som en variabel med hjälp av python-dotenv.

Tänk på att lägga in namnet på din .env fil i din .gitignore fil också så att din API nyckeln inte åker upp på GitHub.

Jag håller med om att TS borde bygga en backend för sin app. Om du inte har en backend kan du inte veta vad dina användare gör (och om dom missbrukar appen), och varje användare måste göra API calls till väder API:n (och detta är nog inte särskilt kostnadseffektivt). Det är också enkelt att bygga och underhålla olika frontends (webbapp, iPhone-app, Android-app etc.) om du har en backend.

Så här hade jag gjort det (med AWS):

• Bygg en REST API där du har all väderdata.

Du kan använda Amazon API Gateway, AWS Lambda, och en databas (t.ex. PostgreSQL). Din frontend gör sedan GET requests för att hämta väderdata.

• Lägg till en AWS Lambda som gör API calls till din väder API och gör POST requests till din REST API (alternativt kan du ändra databasen direkt).

Du kan använda cron jobs med AWS Cloudwatch Events enligt något schema; du kanske väljer att hämta ny väderdata varje 10:e minut. Du kan lägga API-nycklar i environment variables i din AWS Lambda; dom är då krypterad och använder sig av AWS KMS. Ett annat (bättre?) sätt är att använda AWS Secrets Manager.

Identifierar du användarna/klienterna på något vis? Utan identifiering kan fortfarande andra utvecklare utnyttja ditt backend (istället för att utnyttja din API-nyckel).