Áætluð vinnsla eða mannleg innskráning: hvaða auðkenni á API að sjá?

Áætluð vinnsla og manneskja við innskráningarbeiðni kalla á sama API með mismunandi skilríkjum, mismunandi líftíma og mismunandi eigendur. Vinnslan þarf netleið, auðkenni forrits og sett af heimildum; manneskjan þarf innskráningu, annan þátt og lotu. Að blanda þessu tvennu framleiðir sjálfvirkni sem brotnar í hvert sinn sem lykilorð manneskjunnar breytist, eða stefnu með mörgum þáttum sem veikt er rétt svo að cron-vinna haldist á lífi.

Þrjú hlið sem líta út eins og eitt

Regla um upprunafangaskilyrði spyr hvaðan beiðnin kom. Auðkenning spyr hver hringir og hvaða sönnun var lögð fram. Heimild spyr hvort þessi aðili megi framkvæma þessa aðgerð. VPN breytir aðeins því fyrsta af þremur og breytir því fyrir hvert ferli á hýsilnum en ekki aðeins vinnsluna, svo haldið þremur athugunum aðskildum í atvikaskránni.

Þess vegna getur skipt um útgangshnút lagfært höfnun vegna upprunafangs og látið ógilt tákn vera ósnortið. Þess vegna gerir gilt API-tákn ekki einkaleyfisendapunkt aðgengilegan frá vinnslu sem hefur enga leið þangað.

Gagnvirk leið er lélegt sniðmát fyrir sjálfvirkni

Að skrifta innskráningu manneskju er freistandi því það virkar einu sinni. Skriftan geymir lykilorð, kannski fræ að einnota lykilorði, og ræðst síðan af áskorun sem hönnuð er til að krefjast manneskju. Núverandi besta öryggisvenja OAuth, RFC 9700, bannar resource-owner-password-credentials styrkinn og útskýrir hvers vegna hann hentar illa fyrir tveggja þátta og margþrepa auðkenningu.

Yfirleitt er studdur valkostur flæði trúnaðarviðskiptavinar þar sem auðkenningarþjónninn auðkennir forritið og gefur út tákn. Styrkurinn client-credentials í RFC 6749 kafla 4.4 er eitt dæmi. Tilvist hans þýðir ekki að hvert API samþykki hann, né að hægt sé að skipta út verkefni sem notandi framseldi, því það eru spurningar til eiganda þjónustunnar. Spurðu hvaða líkan án eftirlits þjónustan styður áður en þú skrifar kóða.

Hvar VPN á enn heima

VPN getur veitt netleiðina sem einkaleyfis-API krefst, og það er lögmætt hlutverk. Það auðkennir ekki vinnsluna gagnvart forritinu og afmarkar ekki hvað vinnslunni er heimilt að gera. Sameiginlegt útgangsfang auðkennir líka hýsilinn en ekki vinnsluna, svo færsla á heimildalista fyrir það fang hleypir hverju ferli sem þar keyrir inn.

Ef vinnslan keyrir á sameiginlegum keyrsluaðila skiptir sú aðgreining meira en minna máli. Annað verkflæði á sama hýsil erfir leiðina og fangið, og API getur ekki greint þau tvö. Þetta er sama veikleiki og sameiginlegt lykilorð, fært einu lagi neðar. Setjið takmörkunina þar sem forritið getur framfylgt henni, og einangrið keyrsluaðilann ef þið getið ekki þrengt heimildalistann.

Berið saman hönnuðina tvo af heiðarleika

Mannleg innskráning gefur þér raunverulega manneskju, raunverulegan annan þátt og endurskoðanlega lotu, og hún getur ekki keyrt án eftirlits. Auðkenni forrits gefur þér keyrslu án eftirlits, yfirfarið umfang og skilríki sem þú getur snúið, og það getur ekki starfað fyrir notanda sem hefur framselt ekkert. Hvorugt er veikari útgáfa af hinu; þau svara mismunandi spurningum. Veldu með því að spyrja hvort verkefnið verði að keyra án þess að nokkur sé viðstaddur, og hvort aðgerðin verði að vera rakin til tiltekins notanda.

Ef bæði svörin eru já þarf hönnunin framsalslíkan en ekki lánað lykilorð. Skrifaðu þá ákvörðun þar sem næsti viðhaldsaðili finnur hana.

Hvað á að sannreyna fyrir afhendingu

Keyrðu eina leyfða aðgerð og eina skylda höfnun frá raunverulega vinnsluaðilanum, og geymdu bæði niðurstöðurnar. Prófaðu síðan útrunnið skilríki og hegðunina þegar netleiðin er ekki tiltæk, því það eru þau tvö mistök sem vekja einhvern á nóttunni.

curl -sS -o /dev/null -w '%{http_code}\n' \
  -H "Authorization: Bearer TOKEN" https://api.example.com/v1/records

Skráðu aðilann, umfangið, eiganda snúningsins og keyrsluumhverfið við hlið þeirrar niðurstöðu. Þessi skráning er það sem gerir næstu snúninga að venju en ekki atviki. Hún er líka sá hluti sem endurskoðandi biður um.