OAuth

Den aktuelle version af siden er endnu ikke blevet gennemgået af erfarne bidragydere og kan afvige væsentligt fra den version , der blev gennemgået den 21. december 2020; checks kræver 26 redigeringer .

OAuth
Navn	OAuth
Mediefiler på Wikimedia Commons

OAuth  er en åben godkendelsesprotokol (skema) , der giver en tredjepart begrænset adgang til brugerens beskyttede ressourcer uden at overføre et login og adgangskode til den (tredjeparten) [1] [2] .

Arbejdet med protokollen begyndte i november 2006, og den seneste version af OAuth 1.0 blev godkendt den 4. december 2007. Som en efterfølgende udvikling dukkede OAuth 2.0-protokollen op i 2010, hvis seneste version blev offentliggjort i oktober 2012 som RFC 6749 .

Ansøgning

Et af problemerne med autentificering og informationssikkerhed er, at brugere normalt bruger flere forskellige tjenester (f.eks. på Google, Twitter, Apple osv.), og dermed flere konti med deres egne logins og adgangskoder. Brugerne skal således gemme og beskytte mange logins og adgangskoder. Da hver af tjenesterne har sit eget sikkerhedssystem med sine egne sårbarheder og mangler, er alt dette skadeligt for brugernes bekvemmelighed og sikkerhed. For eksempel, hvis brugere bruger de samme adgangskoder til forskellige tjenester, efter at have fået adgang til en af ​​konti, er hacking-proceduren for andre konti for angribere meget forenklet [3] .

Totrinsgodkendelse (f.eks . Google Authenticator ) kan bruges til at øge sikkerheden, når en anden brugertjeneste bruges til bekræftelse (f.eks. når en kode sendt til en mobiltelefon kræves til godkendelse på et websted ). Med denne tilgang reduceres sandsynligheden for hacking betydeligt. Nøglefunktionen ved at bruge OAuth er, at hvis brugeren har en velbeskyttet konto, så kan han ved hjælp af den og OAuth-teknologi godkende sig til andre tjenester, mens brugeren ikke behøver at afsløre sin hovedadgangskode. For eksempel behøver en bruger, der ønsker at give en online fotoudskrivningstjeneste adgang til billeder fra deres Facebook-konto , ikke give tjenesten adgangskoden til den pågældende konto. I stedet giver den autorisation til Facebook, som (med tilladelse fra brugeren eller tjenesteadministratoren) allerede giver onlineudskrivningstjenesten den nødvendige adgang til fotos [3] .

Historie

OAuth 1.0

OAuth dukkede op i november 2006 under udviklingen af ​​OpenID -protokollen til Twitter -mikroblogtjenesten af ​​Blaine Cook .  Sammen med Chris Messina ledte han efter en måde at bruge OpenID til at give adgang til Twitter API uden at give tjenesten en adgangskode. I samarbejde med OpenID co-creator David Recordon analyserede de funktionaliteten af ​​OpenID såvel som proprietære autorisationsprotokoller såsom Flickr Auth , Google AuthSub og Yahoo! BBAuth , hvorefter de kom frem til, at der er behov for en ny åben protokol [4] .    

I april 2007 blev en gruppe ingeniører dannet for at arbejde på dens oprettelse. Ansatte hos Google og AOL (som samtidig introducerede sin egen OpenAuth -protokol ) deltog i dets arbejde. Den endelige version af OAuth 1.0-protokolkernen blev frigivet den 4. december 2007. I 2008 blev der arbejdet med at standardisere protokollen i Internet Engineering Council [4] .

Den 15. april 2009 tilbød Twitter sine brugere en løsning, der tillader tredjepartswebsteder og -tjenester at få adgang til deres konti. Det hed "Log ind med Twitter" og var baseret på OAuth. Denne hændelse udløste protokollens første omfattende sårbarhedsundersøgelse, og få dage senere blev der opdaget en potentiel sårbarhed, der påvirker alle eksisterende OAuth-implementeringer. Derefter, den 23. april, blev den første sikkerhedstilføjelse til protokollen frigivet af udviklerfællesskabet, som var inkluderet i den opdaterede OAuth Core 1.0 Revision A-specifikation, offentliggjort den 24. juni. I april 2010 blev hvidbogen RFC 5849 om OAuth-standarden [4] udgivet .

OAuth 2.0

I 2010 begyndte arbejdet med en ny version af OAuth 2.0-protokollen, der ikke var bagudkompatibel med OAuth 1.0 [1] . I oktober 2012 blev rammen for OAuth 2.0 offentliggjort i RFC 6749 , og brugen af ​​token-bærer i RFC 6750 .

Der var flere forudsætninger for at oprette OAuth 2.0. Først og fremmest er OAuth ret ikke-trivielt at bruge på klientsiden. Et af målene med at udvikle den nye OAuth er at gøre det nemmere at udvikle klientapplikationer. For det andet, på trods af implementeringen af ​​tre metoder (kaldet flows), der er erklæret i standarden for at opnå  et token (unik identifikator) til autorisation: for webapplikationer, desktop-klienter og mobile klienter er alle tre metoder faktisk slået sammen til én. Og for det tredje viste protokollen sig at være dårligt skalerbar. Ud over nye streams blev [5] [6] tilføjet til det :

• Bærertegn . Godkendelsesmetoden ligner den eksisterende cookiegodkendelsesmetode . I dette tilfælde bruges tokenet direkte som en hemmelighed (den blotte eksistens af tokenet autoriserer klienten) og transmitteres via HTTPS . Dette giver dig adgang til API'en gennem simple scripts (for eksempel ved hjælp af cURL ).
• Forenklet signatur . Signaturen er blevet meget forenklet for at eliminere behovet for speciel parsing, kodning og parametersortering.
• Kortlivede tokens med langsigtet autorisation . I stedet for at udstede et token med lang levetid (som kan blive kompromitteret over tid), giver serveren kortsigtet adgang og langsigtet mulighed for at forny tokenet uden brugerindblanding.
• Adskillelse af roller . Forskellige servere kan være ansvarlige for godkendelse og for at give adgang til API'en.

I øjeblikket bruges OAuth 2.0 af en lang række tjenester, såsom Google , Instagram , Facebook , VKontakte og andre.

Senere udvikling

I juli 2012 annoncerede Eran Hammer, den nuværende redaktør af OAuth 2.0-standarden, sin opsigelse efter tre års arbejde med den nye standard og anmodede om, at hans navn blev fjernet fra specifikationerne. Han fortalte om sine synspunkter på sin hjemmeside [7] og holdt senere en tale [8] . David Recordon har også senere slettet sit navn fra specifikationen uden at give grunde [ 9] .  Dick Hardt blev redaktør af OAuth2.0-standarden, og på trods af Eran Hammers synspunkter blev OAuth 2.0-rammeværket offentliggjort i RFC 6749 i oktober 2012 [1] .

Sammenligning med andre protokoller

Fordele

Ved brug af OAuth - autorisation overfører brugeren ikke sit login og password til beskyttede ressourcer direkte til applikationen [3] . Derfor:

• Brugeren har større grund til at stole på applikationen, fordi brugeren kan være sikker på, at uautoriseret adgang til hans personlige data er umulig. Uden at eje brugerens brugernavn og adgangskode, vil applikationen kun være i stand til at udføre de handlinger med de data, som brugeren har tilladt, og ingen andre [3] .
• Når du udvikler en applikation, behøver du ikke sørge for at sikre fortroligheden af ​​brugerens login og adgangskode. Login og adgangskode overføres ikke til applikationen, og de kan derfor ikke falde i hænderne på ubudne gæster [10] .

I tilfælde af autorisation uden brug af OAuth-protokollen skal brugeren sende sit login og adgangskode. Denne metode har yderligere ulemper [3] :

• Hvis brugeren ændrer adgangskoden, kan applikationen ikke længere få adgang til beskyttede ressourcer.
• Den eneste måde at forhindre et program i at få adgang til beskyttede ressourcer er at ændre adgangskoden. Dette vil samtidig nægte adgang til ressourcer og andre applikationer, der tidligere havde det.
• Tjenester, der gemmer beskyttede ressourcer og leverer API'er til at få adgang til dem, kan bruge Federated Authentication - mekanismer såsom OpenID eller SAML , som tillader brugere ikke at have en adgangskode til deres konti .  Dette gør det umuligt for disse brugere at bruge applikationer, der anmoder om adgang til beskyttede ressourcer via denne API.

Forskel fra OpenID

Selvom OAuth og OpenID har meget til fælles, er OAuth en protokol i sig selv og har intet at gøre med OpenID [10] :

• OAuth er en autorisationsprotokol [10] , der giver dig mulighed for at give rettigheder til at bruge en eller anden ressource (f.eks. API'en for en tjeneste). Tilstedeværelsen af ​​rettigheder bestemmes af et token (unik identifikator), som kan være den samme for forskellige brugere, eller én bruger kan have forskellige tokens på forskellige tidspunkter. Tildelingen af ​​rettigheder sker i bytte for tildelingen af ​​et token. Generelt er det umuligt at afgøre, hvem der ejer tokenet, og hvem der i øjeblikket bruger rettighederne.
• OpenID er et autentificeringsværktøj [10] : ved at bruge dette system kan du sikre dig, at brugeren er præcis den, han udgiver sig for at være. Hvilke handlinger der kan udføres af en bruger, der er godkendt af OpenID, bestemmes af den part, der udfører autentificeringen.

Beskrivelse af OAuth-protokoller

Grundlæggende begreber brugt i protokoller og eksempler på deres brug.

Klient-, server- og ressourceejer

OAuth 1.0 definerer tre roller: klient, server og ressourceejer. Disse tre roller er til stede i enhver OAuth-handling, i nogle tilfælde er klienten også ejer af ressourcen. Den originale version af specifikationen bruger et andet sæt udtryk for disse roller: forbruger (klient), service (server) og bruger (ressourceejer) [11] . I OAuth 2.0-protokollen var der en adskillelse af serverroller: en autorisationsserver og en server, der gemmer beskyttede ressourcer, er tildelt separat [6] .

Metoder til oprettelse af signaturer

OAuth understøtter 3 signaturmetoder, der bruges til at signere og validere anmodninger: PLAINTEXT , HMAC - SHA1 og RSA - SHA1 . PLAINTEXT er trivielt at bruge og tager betydeligt mindre tid at beregne, men det kan kun være sikkert over HTTPS eller lignende sikre kanaler. HMAC - SHA1 tilbyder en enkel og generisk algoritme, der er tilgængelig på de fleste platforme, men ikke alle ældre enheder, og bruger en symmetrisk delt nøgle. RSA - SHA1 giver øget sikkerhed med et nøglepar, men er mere kompleks og kræver nøglegenerering [12] .

Tidsstempel og ikke

For at forhindre truslen om genbrug af anmodninger bruger OAuth en nonce og et tidsstempel . Udtrykket "nonce" bruges til at henvise til en engangskode, som er et tilfældigt sæt bogstaver og tal og er designet til entydigt at identificere en anmodning. At have en unik identifikator i en anmodning giver tjenesteudbyderen mulighed for at forhindre, at den genbruges. Denne tilgang implementeres ved at generere en unik streng for hver anmodning sendt til serveren af ​​klienten. For at forhindre genbrug af anmodninger SKAL serveren gemme modtagne nonces [12] .

Det kan dog være meget dyrt for serveren at gemme alle modtagne nonces. For at forhindre overdreven lageroverhead i OAuth tilføjes et tidsstempel til hver anmodning, som tillader serveren kun at gemme nonce i en specificeret begrænset tid. Ved modtagelse af en anmodning med en etiket tidligere end tilladt, afviser serveren den [12] .

Kræfter og tokens

OAuth 1.0 og OAuth 2.0 bruger tre typer autoritet: klientlegitimationsoplysninger ( forbrugernøgle  og hemmelig eller klientlegitimationsoplysninger ) ,  midlertidige legitimationsoplysninger ( anmodningstoken og hemmelige eller midlertidige legitimationsoplysninger ) og tokens ( adgangstoken og hemmelige eller engelske tokenslegitimationsoplysninger ) [13] [ 3] .     

Klientlegitimationsoplysningerne bruges til at godkende klienten. Serveren kan levere specielle tjenester til klienter, såsom at begrænse fri adgang eller give ressourceejeren mere detaljerede oplysninger om klienter, der forsøger at få adgang til beskyttede ressourcer. I nogle tilfælde er klientlegitimationsoplysningerne ikke sikre og kan kun bruges til informationsformål, såsom i desktop-applikationer.

Tokenet bruges i stedet for ressourceejerens navn og adgangskode. Ressourceejeren afslører ikke sine legitimationsoplysninger til klienten, men tillader serveren at udstede et token til klienten - en særlig klasse af legitimationsoplysninger, der giver klienten nogle begrænsede muligheder. Klienten bruger tokenet til at få adgang til en beskyttet ressource uden at kende ressourceejerens adgangskode. Tokenet består af en digital signatur, normalt (men ikke altid) et tilfældigt sæt bogstaver og tal, der er unikt og kryptografisk stærkt, og en nøgle til at beskytte tokenet mod uautoriseret brug. Tokenet er begrænset med hensyn til autoritet og varighed og kan til enhver tid tilbagekaldes af ejeren af ​​ressourcen, uden at det påvirker tokens udstedt til andre klienter [13] .

OAuth-godkendelsesprocessen bruger også et sæt midlertidige legitimationsoplysninger, der bruges i godkendelsesanmodningsfasen. For at tage højde for forskellige typer klienter (webgrænseflade, desktop, mobil osv.), tilbyder midlertidige tilladelser yderligere fleksibilitet og sikkerhed [13] .

OAuth 1.0

Lad os forklare, hvordan OAuth 1.0-protokollen fungerer ved hjælp af et eksempel [13] . Antag, at en bruger (ressourceejer) ønsker at udskrive deres fotos (ressourcer) uploadet til photos.example.net (server) ved hjælp af printtjenesten "printer.example.net" (klient).

1. Klienten sender en anmodning til serveren via HTTPS -protokollen , som indeholder klient-id, tidsstempel, tilbagekaldsadresse (bruger den til at returnere tokenet), typen af ​​digital signatur , der bruges, og selve signaturen.
2. Serveren anerkender anmodningen og svarer klienten med et anmodningstoken og  en del af den delte hemmelighed.
3. Klienten videregiver tokenet til ressourceejeren (brugeren) og omdirigerer det til serveren til godkendelse.
4. Serveren, efter at have modtaget et token fra brugeren, beder ham om hans login og adgangskode, og i tilfælde af vellykket autentificering beder den brugeren om at bekræfte klientens adgang til ressourcer (autorisation sker), hvorefter brugeren omdirigeres af serveren til klienten.
5. Klienten sender et anmodningstoken til serveren via TLS-protokollen og anmoder om adgang til ressourcer.
6. Serveren anerkender anmodningen og svarer klienten med et nyt adgangstoken . 
7. Ved hjælp af et adgangstoken får klienten adgang til serveren for ressourcer.
8. Serveren anerkender anmodningen og leverer ressourcerne.

OAuth 2.0

OAuth 2.0-protokollen er ikke bagudkompatibel med OAuth 1.0-protokollen [1] . I stedet for at komplementere OAuth 1.0, blev beslutningen taget om at udvikle en anden protokol [10] . Derfor er den måde, OAuth 1.0 og OAuth 2.0 fungerer på, forskellig. Så i OAuth 2.0-standarden er følgende flows (scenarier for interaktion mellem parterne) [1] beskrevet :

• Implicit  bevillingsflow _ _

Er det korteste protokolflow: Brugeren bliver først omdirigeret af klienten til serveren for at give adgang til ressourcer, og efter at der er givet adgang, omdirigeres den af ​​serveren tilbage til klienten [10] .

• Flow med bekræftelseskode ( eng.  Authorization Code Flow )

Forskellen mellem dette flow og det implicitte adgangsflow ligger i det ekstra trin af klientgodkendelse [10] .

• Opdatering af et  udløbet adgangstokenflow

Forskellene mellem dette flow og ovenstående eksempel er som følger: ved trin 2 udsteder serveren, ud over adgangstokenet, som har en begrænset levetid, et opdateringstoken; i trin 8 kontrollerer serveren, om adgangstokenet er gyldigt (i betydningen udløb af levetiden), og afhængigt af dette giver den enten adgang til ressourcer eller kræver en opdatering af adgangstoken (som leveres ved præsentation af et opdateringstoken ).

• Flow med legitimationsoplysninger til  ressourceejer- adgangskode

I dette flow giver ressourceejeren klienten et login og en adgangskode, han sender dem til serveren og modtager et token for at få adgang til ressourcerne. På trods af at denne funktionsmåde i nogen grad modsiger konceptet med at skabe en protokol, er den beskrevet i specifikationen.

• Klientlegitimationsflow  _ _ _

I denne funktionsmåde af protokollen giver serveren et adgangstoken, efter at klienten har overført sin bruger og adgangskode, som tidligere blev indstillet af autorisationsserveren (specifikationen angiver ikke hvordan). Faktisk passerer klienten straks både autorisation og autentificering.

OAuth understøtter to metoder til godkendelse af meddelelser fra klienten: HMAC - SHA1 og RSA - SHA1 . Det er muligt at sende beskeder uden signatur, så er " almindelig tekst " angivet i signaturtypefeltet. Men i dette tilfælde skal forbindelsen mellem klienten og serveren ifølge specifikationen etableres via SSL- eller TLS-protokollen [13] .

Noter

1. ↑ 1 2 3 4 5 D. Hardt, Ed. OAuth 2.0 Authorization Framework . Introduktion  (engelsk) . Internet Engineering Task Force (oktober 2012) . Hentet 30. oktober 2015. Arkiveret fra originalen 14. maj 2016.
2. ↑ E. Hammer-Lahav, red. OAuth 1.0 - protokollen   // IETF . - 2010. - April. — ISSN 2070-1721 .
3. ↑ 1 2 3 4 5 6 Gibbons K. , Raw J. O. , Curran K. Security Evaluation of the OAuth 2.0 Framework  // Information Management and Computer Security - Emerald Publishing Limited , 2014. - Vol . 22, Iss. 3. - ISSN 0968-5227 ; 1758-5805
4. ↑ 1 2 3 Eran Hammer. OAuth 1.0-vejledningen. Historie  (engelsk) . Hentet 30. oktober 2015. Arkiveret fra originalen 25. oktober 2015.
5. ↑ Eran Hammer. Introduktion til OAuth 2.0  (  dødt link) . hueniverse.com. Dato for adgang: 30. oktober 2015. Arkiveret fra originalen 15. januar 2011.
6. ↑ 1 2 Ryan Boyd. Introduktion // Kom godt i gang med OAuth 2.0 . - 1. udg. - 1005 Gravenstein Highway North, Sebastopol: O'Reilly Media, Inc., 2012. - S. 67. - 9-12, 23-24 s. - ISBN 978-1-449-31160-5 .
7. ↑ Eran Hammer. OAuth 2.0 og vejen til helvede  (engelsk)  (link ikke tilgængeligt) . hueniverse (26. juli 2012). Hentet 14. juni 2017. Arkiveret fra originalen 25. marts 2013.
8. ↑ Eran Hammer. OAuth 2.0 - At se tilbage og komme  videre . hueniverse. Dato for adgang: 30. oktober 2015. Arkiveret fra originalen 22. oktober 2015.
9. ↑ D. Hardt. OAuth 2.0-autorisationsrammen: Bearer Token Usage draft-ietf-oauth-v2-bearer-23 . Bilag B. Dokumenthistorik  ( 1. august 2012) . Dato for adgang: 30. oktober 2015. Arkiveret fra originalen 16. november 2015.
10. ↑ 1 2 3 4 5 6 7 Chen E. Y. , Pei Y. , Chen S. , Tian Y. , Kotcher R. , Tague P. OAuth Demystified for Mobile Application Developers  // Proceedings of the 2014 ACM SIGSAC Conference on - NYC : ACM , 2014. - P. 892-903. - ISBN 978-1-4503-2957-6 - doi:10.1145/2660267.2660323
11. ↑ Eran Hammer. Terminologi  (engelsk) . hueniverse. Dato for adgang: 31. oktober 2015. Arkiveret fra originalen 1. november 2015.
12. ↑ 1 2 3 Eran Hammer. Sikkerhedsramme  . _ hueniverse. Hentet 31. oktober 2015. Arkiveret fra originalen 5. november 2015.
13. ↑ 1 2 3 4 5 E. Hammer-Lahav, red. OAuth 1.0-  protokollen . Internet Engineering Task Force . Hentet 8. november 2015. Arkiveret fra originalen 10. november 2015.

Links

• oauth.net ​(  eng.) - den officielle side for OAuth

Autentificering og nøgleudvekslingsprotokoller
Med symmetriske algoritmer	Bred Mund Frø Yahalom Needham-Schroeder-protokollen Otway-Risa-protokollen Kerberos Newman-Stubblebine-protokollen
Med symmetriske og asymmetriske algoritmer	DASS Denning-Sacco-protokollen Wu Lam-protokollen SPKM
Protokoller og tjenester, der bruges på internettet	OAuth Åbn ID Windows Live ID