Definiera omfattningar före skapande
Ge en nyckel endast de åtgärder och resurser som dess uppgift kräver. En övervakningsintegration kan behöva läsbehörighet; ett distributionsverktyg kan behöva en definierad uppsättning livscykelåtgärder. Håll faktureringsbehörighet separat där det är möjligt.
Avslöja försiktigt och lagra privat
En riktig nyckel bör visas genom ett säkert skapandeflöde, skyddas i vila och uteslutas från URL, webbläsarpaket och källkontroll. Registrera ägare, syfte och skapandetid utan att exponera själva hemligheten.
Gör återkallande praktiskt
Utfärda separata autentiseringsuppgifter per integration så att en kan återkallas utan att allt stoppas. Rotera medvetet och verifiera att den gamla nyckeln inte längre fungerar. Undersök oväntad användning med begränsade granskningsposter.
Testa gränserna
Ett användbart lanseringstest omfattar en tillåten åtgärd, en förbjuden åtgärd, en utgången eller återkallad nyckel och en förfrågan utanför nyckelns resursgräns. Autentisering ensamt är inte auktorisering.
Policy för kandidatnycklar
API-avtalet beskriver upp till tio aktiva nycklar per konto, med namngivna syften, valfri utgång och begränsningar för källadress. Omfattningar separerar läsning, serverhantering, fakturering och full kontroll. Ett skapandeflöde bör visa hemligheten en gång och endast behålla en lämpligt skyddad verifieringsrepresentation.
Granska utan att exponera förfrågan
En användbar granskningslogg kan innehålla nyckelidentifierare, rutt, tid och resultat utan att lagra lösenord eller hela förfrågningskroppar. Åtkomst till loggen behöver fortfarande skyddas. Definiera lagring och export i stället för att behålla känslig drifthistorik på obestämd tid.
Ge varje automatisering en egen autentiseringsuppgift
En säkerhetskopiekontroll, distributionsarbetare och faktureringsintegration bör inte dela samma nyckel med full åtkomst. Namnge en nyckel efter dess uppgift, bevilja minsta omfattning och registrera vem som äger den. De avsedda grupperna är läsning, servrar, fakturering och full; deras exakta åtgärdsmappning måste testas när API blir tillgänglig.
Skapande, lagring och rotation
Den föreslagna kontomodellen tillåter upp till tio aktiva nycklar. Visa en ny hemlighet en gång och behåll sedan endast den server-sidiga verifierare som behövs för att autentisera den. Lagra klientkopian i en hemlighetshanterare eller skyddad tjänstemiljö. Rotera genom att införa en ersättning, kontrollera den beroende arbetaren och sedan återkalla den gamla nyckeln; placera aldrig en nyckel i ett offentligt URL eller webbläsarpaket.
Återkalla åtkomsten, inte bevisningen
Att inaktivera en nyckel bör stoppa framtida begäranden samtidigt som en begränsad säkerhetsregistrering av dess tidigare användning bevaras. Om en autentiseringsuppgift kan ha läckt, återkalla den snabbt, granska berörda resurser och ersätt eventuella relaterade hemligheter. En nyckellista bör visa en säker identifierare och metadata om senaste användning i stället för återställbara hemligheter i klartext.
Lite mer klarhet.
Kan den här sidan skapa en fungerande API-nyckel?
Nej. Nyckelskapande kräver en autentiserad kontobackend; denna informationssida utfärdar inga autentiseringsuppgifter.