OAuth

OAuth er en åpen, standard nettverksprotokoll designet spesielt for å fungere med Hypertext Transfer Protocol (HTTP) . I hovedsak tillater det utstedelse av et tilgangstoken fra en autorisasjonsserver til en tredjepartsklient, med forbehold om godkjenning fra brukeren som eier ressursen som skal aksesseres. [1]

Denne mekanismen, kalt "tilgangsdelegering", brukes av selskaper som: Amazon, Google, Facebook, Microsoft, Twitter, Dropbox for å la brukeren dele informasjon om kontoen sin med andre applikasjoner eller nettsteder. . Det brukes ofte som en måte for Internett-brukere å gi applikasjoner og nettsteder tilgang til informasjonen deres uten å gi dem et passord.

Denne protokollen tillater autorisasjon av sikkerhets- APIer med en standard og enkel metode i ulike situasjoner: "mobile" applikasjoner, "web" applikasjoner, applikasjoner for personlige datamaskiner.

For applikasjonsutviklere er det en måte å publisere og samhandle med beskyttet data. OAuth gir tjenesteleverandører tredjeparts tilgang til brukerdata samtidig som den beskytter deres legitimasjon. For eksempel lar den brukeren gi et nettsted, kalt en forbruker, tilgang til informasjon på et annet nettsted, kalt en tjenesteleverandør, uten å dele identiteten sin.

Historie og versjoner

Utviklet av Blaine Cook og Chris Messina fra november 2006 .

OAuth 1.0-protokollen ble publisert som RFC 5849 i april 2010.

En videreutvikling av OAuth 1.0, det er OAuth 2.0 som er beskrevet i RFC 6749- dokumentet fra oktober 2012.

Skuespillere

I OAuth er det følgende hovedaktører:

brukeren eller ressurseieren _
kunden eller forbrukeren _
ressursserveren eller tjenesteleverandøren _
autorisasjonsserveren _

Ressurseieren er personen som kan gi tilgang til en del av kontoen sin. Han er personen som kan garantere tilgang til de beskyttede ressursene på "Ressursserveren".

Klienten er applikasjonen som prøver å få tilgang til brukerens konto og ber om tillatelse fra "Brukeren" før den kan få tilgang til de beskyttede ressursene.

Ressursserveren er serveren som brukes for å få tilgang til brukerens beskyttede ressurser.

Autorisasjonsserveren er serveren som presenterer grensesnittet der brukeren godkjenner eller nekter tilgangsforespørselen. I små miljøer kan det falle sammen med ressursserveren .

Klienten samhandler med ressursserveren for å få midlertidig legitimasjon. For å få tilgang til beskyttede ressurser, ber klienten brukeren om tillatelse, kjent som tilgangstoken. Når tilgangstokenet er oppnådd, kan det få tilgang til og samhandle med etablerte ressurser i kort tid.

OAuth 1.0

Årsaker

Den grunnleggende ideen er å la tredjeparter administrere private dokumenter uten å dele passordet. Faktisk har delingen av passordet mange begrensninger når det gjelder sikkerhet, slik som at det for eksempel ikke garanterer støtte for individuelle privilegier på enkelte filer eller operasjoner, og fremfor alt gjør det hele kontoen og administrasjonspanelet tilgjengelig. Spesielt er denne ubetingede tilgangen uønsket. Dessuten er den eneste måten å tilbakekalle tilgang på å endre passordet for hele kontoen.

OAuth ble derfor født med premisset om å garantere delegert tilgang til en spesifikk klient for visse ressurser på serveren i en begrenset tid, med mulighet for tilbakekall.

Sikkerhet og begrensninger

OAuth 1.0 har noen sikkerhetsbegrensninger. Serveren utfører ikke denne tjenesten "gratis", men samler inn informasjon om brukeren, klienten og deres interaksjon. OAuth 1.0 garanterer ikke konfidensialitet verken på forespørsler eller på innhold. Selv om denne protokollen sikrer at klienten ikke får tilgang til uønsket informasjon, garanterer den ikke at bruken av autoriserte ressurser forblir innenfor det angitte omfanget. Av denne grunn foreslår OAuth serveren å beskytte ressursene gjennom TLS -protokollen .

For å sikre informasjonsintegritet tilbyr OAuth 3 forskjellige metoder:

Klartekst -> brukes kun med HTTPS -protokollen ;
HMAC
RSA

Et annet kjent problem er phishing . Klienten kan henvise brukeren til en falsk serverpåloggingsside for å be om autentisering og få brukerens legitimasjon.

OAuth 2.0

En utvikling av OAuth 1.0 er beskrevet i RFC 6749- dokumentet fra oktober 2012. Driftsprinsippet er det samme, men det skiller seg fra forgjengeren for noen forbedringer i tjenesten. Faktisk presenterer OAuth 2.0 en klar rollefordeling, og implementerer en mediator mellom klient og server. En annen fordel i forhold til den forrige versjonen er muligheten for å forlenge brukstiden for tilgangstoken om ønskelig.

Aktørene er de samme med tillegg av en mediatorserver. Sistnevnte har som hovedoppgave å administrere tilgangstokener mellom klient og server. Serveren som fungerer som en mediator kan være den samme serveren som er vert for ressursene som skal aksesseres. Meglerserveren kan administrere tilgangstokener fra mer enn én server.

Grensene for OAuth 2.0 er de samme som for OAuth 1.0. Disse to Oauth-protokollene er ikke kompatible med hverandre.

Sikkerhet

I april-mai 2017 ble rundt én million «Gmail»-brukere (mindre enn 0,1 % av brukerne per mai 2017) utsatt for et OAuth-basert phishing-angrep. Disse brukerne mottok en e-post som utgir seg for å komme fra en kollega, ansatt eller venn som ønsket å dele et dokument på «Google Docs» [2] . De som klikket på koblingen i e-posten ble bedt om å logge på og gi et potensielt skadelig tredjepartsprogram kalt "Google Apps" tilgang til e-postkontoene, kontaktene og elektroniske dokumenter. Phishing-angrepet ble blokkert av «Google» på omtrent én time ved å advare de som hadde gitt tilgang til e-posten deres til «Google Apps» om å trekke tilbake tilgangen og endre passordet.

Merknader

^ Dick Hardt, The OAuth 2.0 Authorization Framework , på tools.ietf.org . Hentet 22. februar 2019 .
^ Google Docs phishing-e-post 'koster Minnesota $ 90 000' - BBC News , på web.archive.org , 8. mai 2017. Hentet 2. januar 2021 (arkivert fra originalen 8. mai 2017) .