Planne baan of minsklike oanmelding: hokker identiteit moat de API sjen?

In plande baan en in persoan by in oanmeldprompt roppe deselde API oan mei ferskillende legitimaaasjes, ferskillende libbensduorren en ferskillende eigners. De baan hat in netwurkpaad, in applikaasje-identiteit en in set fan tastimmingen nedich; de persoan hat in oanmelding, in twadde faktor en in sesje nedich. It mingen fan beide leveret automatisearring op dy't brekt eltse kear as it wachtwurd fan 'e persoan feroaret, of in multifaktorbelied dat krekt genôch ferswakke wurdt om in cron-baan libben te hâlden.

Trije poarten dy't op ien lykje

In boarne-adresregel freget wêr't it fersyk weikaam. Autentikaasje freget wa't der skilje en hokker bewiis oanlevere is. Autorisaaasje freget oft dit prinsipe dizze operaasje útfiere mei. In VPN feroaret allinnich de earste fan 'e trije, en it feroaret dy foar elk proses op 'e host en net allinnich foar de baan, dus hâld de trije observaasjes apart yn it ynsidintferslach.

Dêrom kin it feroarjen fan 'e útgongsknoop in ôfwizing op boarne-adres oplosse en in ûnjildich token ûnoantaast litte. Dêrom makket in jildich API-token in privee einpunt ek net berikber fan in baan dy't der gjin rûte nei hat.

It ynteraktive paad is in min sjabloan foar automatisearring

It skriptsjen fan 'e oanmelding fan in persoan is ferloklik om't it ien kear wurket. It skript bewarret in wachtwurd, miskien in ienmalige-wachtwurdsied, en hinget dan ôf fan in útdaging dy't ûntwurpen is om in minske te easkjen. De bêste hjoeddeiske feilichheidspraktyk foar OAuth, RFC 9700, ferbiedt de resource-owner-password-credentials-jefte en ferklearret wêrom't dy min past by twafaktor- en mearstap-autentikaasje.

It stipe alternatyf is meastal in fertroulike-kliïntstream wêryn't de autorisaasjeserver de applikaasje autentisearret en in token útjout. De client-credentials-jefte yn RFC 6749 paragraaf 4.4 is ien foarbyld. It bestean dêrfan betsjut net dat elke API dy akseptearret, of dat in troch in brûker delegearre taak dermei ferfongen wurde kin, want dat binne fragen foar de tsjinst-eigner. Freegje hokker net-besjoen model de tsjinst stipet foardat jo koade skriuwe.

Wêr't de VPN noch thúsheart

In VPN kin it netwurkpaad leverje dat in privee API easket, en dat is in legitime rol. It autentisearret de baan net by de applikaasje, en it beheint net wat de baan dwaan mei. In dielde útgongsadres identifisearret ek de host en net de baan, dus in yngong yn 'e tastienlist foar dat adres lit elk proses troch dat derop draait.

As de baan op in dielde runner draait, is dat ûnderskie wichtiger ynstee fan minder wichtich. In oare workflow op deselde host erft de rûte en it adres, en de API kin de twa net ûnderskiede. It is deselde swakheid as in dield wachtwurd, ien laach nei ûnderen ferpleatst. Set de beheining dêr't de applikaasje dy hanthavenje kin, en isolearje de runner as jo de tastienlist net strakker krije.

Fergelykje de twa ûntwerpen earlik

In minsklike oanmelding jout jo in echte persoan, in echte twadde faktor en in auditeare sesje, en dy kin net sûnder tafersjoch draaie. In applikaasje-identiteit jout jo net-besjoende útfiering, in neigeanber berik en in legitimaaasje dy't jo rotearje kinne, en dy kin net hannelje foar in brûker dy't neat delegearre hat. Gjin fan beide is in swakkere ferzje fan 'e oare; se beantwurdzje ferskillende fragen. Kies troch te freegjen oft de taak sûnder immen oanwêzich draaie moat, en oft de operaasje oan in spesifike brûker taskreaun wurde moat.

As beide antwurden ja binne, hat it ûntwerp in delegaasjemodel nedich ynstee fan in liend wachtwurd. Skriuw dat beslút del dêr't de folgjende ûnderhâlder it fine sil.

Wat te ferifiearjen foar de oerdracht

Fier ien tastiene operaasje en ien ferplichte ôfwizing út fan 'e werklike worker, en hâld beide resultaten. Test dan in ferrûn legitimaaasje en it gedrach as it netwurkpaad net beskikber is, want dat binne de twa steuringen dy't immen nachts wekker meitsje.

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

Skriuw it prinsipe, it berik, de eigner fan 'e rotaasje en de útfieringsomjouwing njonken dat resultaat. Dat ferslach is wat de folgjende rotaasje routine makket ynstee fan in ynsidint. It is ek it diel dat in auditor freget.