Redigerer Sikring av vev-API

'''Sikring av vev-API''' innebærer å [[Autentisering|autentisere]] programmer eller brukere som kaller et [[Web-API|vev API]].

Sammen med enkelheten med API-integrasjoner kommer kompleksiteten med å sikre riktig [[autentisering]] og [[autorisering]]. I et miljø med flerleie (''multi tenant'') kan sikkerhetskontroller basert på riktig autentisering og autorisering bidra til å sikre at API-tilgang begrenses til de som trenger det og har rett på dette. Passende metoder for au''tent''isering gjør det mulig for produsenter av API-er eller tjenester å på riktig måte identifisere forbrukere (klienter eller kallende programmer) og evaluere tilgangsnivået deres (au''tori''sering). Med andre ord hvorvidt en [[forbruker]] kan kalle en en bestemt metode (forretningslogikk) basert på den presenterte [[Legitimasjon|legitimasjonen]].

Ifølge en publisert tekst<ref>{{Kilde www|url=https://www.cl.cam.ac.uk/~rja14/Papers/SEv2-c18.pdf|tittel=API Attacks}}</ref> er designfeil i grensesnitt utbredt, og kan finnes blant annet i "[[CPU|prosessorer]] brukt til [[kryptografi]], diverse [[Innebygd system|innebygde systemer]], [[Antivirusprogram|antivirusprogrammer]] og [[Operativsystem|operativsystemer]]."

== Metoder for autentisering og autorisering ==
Vanlige metoder for autentisering og autorisering inkluderer.

# '''Statiske strenger''': Disse er som passord som leveres av API-er til forbrukerne.
# '''Dynamiske polletter''' (''dynamic tokens''): Dette er tidsbaserte polletter gitt til den kallende fra en autentiseringstjeneste.
# '''Brukertildelte polletter''' (''user-delegated tokens''): Dette er polletter som for eksempel [[OAuth]]<ref>{{Kilde www|url=http://oauth.net/2/|tittel=OAuth 2.0 — OAuth|besøksdato=2015-10-10}}</ref> som er blir gitt basert på brukerautentisering.
# '''Policy- og [[Attributtbasert tilgangskontroll|attributtbasert tilgangsstyring]]''': Policyer bruker attributter til å definere hvordan API-er kan kalles ved hjelp av standarder som [[ALFA (XACML)|ALFA]] eller [[XACML]].

De ovennevnte metodene gir forskjellige nivåer av sikkerhet og enkelhet av integrasjon. Ofte tilbyr den enkleste integrasjonsmetoden også den svakeste sikkerhetsmodellen.

=== Statiske strenger ===
[[Fil:Wiki_basicAuth.jpg|miniatyr|Blokkdiagram for enkel autentisering]]
I metoden med statiske strenger legger API-kalleren eller klienten inn en streng som en pollett i forespørselen. Denne metoden er ofte referert til som [http://www.w3.org/Protocols/HTTP/1.0/spec.html#BasicAA '''basic authentication'''] ("enkel godkjenning"). 

Ifølge Jan Wolter<ref name=":0">{{Kilde www|url=http://unixpapa.com/auth/basic.html|tittel=A Guide to Web Authentication Alternatives: Part 2|besøksdato=2015-10-10}}</ref> er denne løsningen ikke veldig tilfredsstillende med tanke på sikkerhet, ettersom det innebærer å sende brukerens passord over nettverket i klartekst (med mindre man benytter en sikker protokoll på et lavere nivå som for eksempel [[Proxytjener|SSL]] for å kryptere alle transaksjoner). Brukeren er dermed veldig sårbar for [[Pakkesniffer|pakkesniffere]] på nettet.<ref name=":0" />

=== Dynamiske polletter (''dynamic tokens'') ===
Når et [[Programmeringsgrensesnitt|API]] beskyttes av en dynamisk pollett gjøres dette ved å sette inn en tidsbasert [[Kryptografisk nonce|nonce]] i polletten. Polletten har en begrenset levetid (''time to live'', TTL) hvoretter klienten må skaffe seg en ny pollett. Denne API-metoden har en tidskontroll-[[algoritme]], og dersom polletten er utløpt vil forespørselen avslås (''request forbidden''). [[JSON Web Token]] er et eksempel på en slik pollett, og der setter exp-kravet utløpstiden (''expiration time'') som sier når JWT ikke lenger kan akseptere forespørsler for behandling.<ref>{{Kilde www|url=https://tools.ietf.org/html/rfc7519|tittel=JSON Web Token (JWT)|besøksdato=2015-10-10|fornavn=Bradley|etternavn=John}}</ref>

=== Brukertildelte polletter (''user delegated token'') ===
Denne typen pollett brukes i trebeinte systemer hvor en [[Applikasjonsprogramvare|applikasjon]] trenger å få tilgang til et API på vegne av en bruker. Istedet for å dele bruker-ID og passord til programmet gir brukeren ut en pollett som innkapsler brukernes tillatelse til at applikasjonen kan kalle API-et.

Autorisasjonsrammeverket OAuth 2.0 gjør det mulig for et tredjepartsprogram å få begrenset tilgang til en [[HTTP|HTTP-tjeneste]], enten på vegne av en ressurseier ved å organisere en godkjenningsinteraksjon mellom ressurseieren og HTTP-tjenesten, eller ved å la tredjepartsprogrammet selv få tilgang.<ref>{{Kilde www|url=https://tools.ietf.org/html/rfc6749|tittel=The OAuth 2.0 Authorization Framework|besøksdato=2015-10-11|fornavn=Dick|etternavn=Hardt}}</ref>

== Finkornet autorisering for API-er ==

=== Attributtbasert tilgangskontroll ===
Med denne tilnærmingen er det et håndhevelsen av retninglinjer (''policy'') enten innenfor selve API-et, i API-rammeverket (som en avskjæringsanordning eller meldingsbehandler) eller som en API-portner (''gateway'') som for eksempel WSO2, Kong eller lignende, som fanger opp kallet til API-et og/eller svaret tilbake fra API-et. Den konverteres så til en autorisasjonsforespørsel (vanligvis i XACML) som sendes til et policybeslutningspunkt (''Policy Decision Point'', PDP), for eksempel AuthZForce eller Axiomatics. Policybeslutningspunktet er konfigurert med policyer som implementerer dynamisk tilgangskontroll som kan bruke et hvilket som helst antall bruker-, ressurs-, operasjon- og kontekst-attributter for å definere hvilken tilgang som tillates eller ikke. Policyen kan handle om:

# Ressursen (for eksempel en bankkonto)
# Brukeren (for eksempel en kunde)
# Kontekst (for eksempel tid på dagen)
# En relasjon (for eksempel kunden som kontoen tilhører).

Retningslinjene blir ofte uttrykt med pseudokodespråk for tilgangskontroll som eXtensible Access Control Markup Language (XACML) eller Abbreviated Language For Authorization (ALFA).

== Referanser ==
<references/>

[[Kategori:Internett-protokoller]]
[[Kategori:Grensesnitt for programvare]]