Planlagd jobb eller menneskeleg innlogging: kva identitet skal API-et sjå?

Ein planlagd jobb og ein person ved ei innloggingsforespurnad kallar det same API-et med ulike legitimasjonar, ulik levetid og ulike eigarar. Jobben treng ein nettverkssti, ein applikasjonsidentitet og eit sett med løyve; personen treng ei innlogging, ein andre faktor og ei økt. Å blande dei to gir automatisering som bryt kvar gong passordet til personen blir endra, eller ein multifaktorpolicy svekt akkurat nok til å halde ein cron-jobb i live.

Tre portar som ser ut som éin

Ein kjeldeadresseregel spør kvar førespurnaden kom frå. Autentisering spør kven som ringjer og kva bevis som blei lagde fram. Autorisasjon spør om denne prinsipalen kan utføre denne operasjonen. Ein VPN endrar berre den første av dei tre, og han endrar han for kvar prosess på verten og ikkje berre for jobben, så hald dei tre observasjonane åtskilde i hendingsrapporten.

Det er difor eit byte av utgangsnode kan rette ei avvising på kjeldeadressa og la eit ugyldig token vere urørt. Det er òg difor eit gyldig API-token ikkje gjer eit privat endepunkt tilgjengeleg frå ein jobb som ikkje har rute dit.

Den interaktive vegen er ein dårleg mal for automatisering

Å skripte innlogginga til ein person er freistande fordi det verkar éin gong. Skriptet lagrar eit passord, kanskje eit eingongspassordfrø, og er deretter avhengig av ei utfordring som er laga for å krevje eit menneske. Den beste gjeldande sikkerheitspraksisen for OAuth, RFC 9700, forbyr resource-owner-password-credentials-tildelinga og forklarer kvifor ho passar dårleg til tofaktor- og fleirtrinnsautentisering.

Det støtta alternativet er vanlegvis ein fortruleg klientflyt der autorisasjonsserveren autentiserer applikasjonen og gjev ut eit token. Client-credentials-tildelinga i RFC 6749 avsnitt 4.4 er eitt døme. At ho finst betyr ikkje at kvart API godtek ho, eller at ein brukardelegett oppgåve kan erstattast av ho, for det er spørsmål til tenesteeigaren. Spør kva uovervaka modell tenesta støttar før du skriv kode.

Kvar VPN framleis høyrer heime

Ein VPN kan levere nettverksstien eit privat API krev, og det er ei legitim rolle. Han autentiserer ikkje jobben overfor applikasjonen, og han avgrensar ikkje kva jobben kan gjere. Ei delt utgangsadresse identifiserer òg verten og ikkje jobben, så ein løyveslistepost for den adressa slepp inn kvar prosess som køyrer på ho.

Køyrer jobben på ein delt runner, er den skilnaden viktigare snarare enn mindre viktig. Ein annan arbeidsflyt på same vert arvar ruta og adressa, og API-et kan ikkje skilje dei to. Det er same svakheit som eit delt passord, flytta eitt lag ned. Set avgrensinga der applikasjonen kan handheve ho, og isoler runneren om du ikkje kan gjere løyveslista strammare.

Samanlikn dei to designa ærleg

Ei menneskeleg innlogging gjev deg ein ekte person, ein ekte andre faktor og ei økt som kan reviderast, og ho kan ikkje køyre uovervaka. Ein applikasjonsidentitet gjev deg uovervaka køyring, eit gjennomgåeleg omfang og ein legitimasjon du kan rotere, og han kan ikkje handle for ein brukar som ikkje har delegert noko. Ingen av dei er ein svakare versjon av den andre; dei svarar på ulike spørsmål. Vel ved å spørje om oppgåva må køyre utan nokon til stades, og om operasjonen må tilskrivast ein bestemd brukar.

Er begge svara ja, treng designet ein delegeringsmodell i staden for eit lånt passord. Skriv den avgjerda ned der neste vedlikehaldar finn ho.

Kva som må verifiserast før overlevering

Køyr éin tillaten operasjon og éi påkravd avvising frå den faktiske workeren, og ta vare på begge resultata. Test deretter ein utlopen legitimasjon og åtferda når nettverksstien ikkje er tilgjengeleg, for det er dei to feila som vekkjer nokon om natta.

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

Noter prinsipalen, omfanget, rotasjonseigaren og køyremiljøet ved sida av det resultatet. Den registreringa er det som gjer den neste rotasjonen rutinemessig i staden for ei hending. Det er òg den delen ein revisor spør etter.