OpenID vs. pseudo-autentisering ved Hjelp Av OAuth
**OAuth** (**O**pen **Auth**orization) er en åpen standard for tilgangsdelegering, og er ofte brukt av internettbrukere for å gi nettsteder eller applikasjoner tilgang til deres informasjon på andre nettsteder, men uten å gi fra seg passord, ved å istedet bruke tilgangspolletter (*access tokens*).

OAuth brukes blant annet av selskaper som Amazon, Google, Facebook, Microsoft, og Twitter for å gjøre det mulig for brukere å dele informasjon om sine kontoer med tredjeparts-applikasjoner eller -nettsteder.

Oversikt
--------

OAuth gir klienter en "sikker delegert tilgang" til serverressurser på vegne av en ressurseier, og dette skjer gjennom en prosess hvor ressurseieren godkjenner tredjeparters tilgang til serverressursene uten å oppgi legitimasjon. Standarden er designet for å fungere med hypertekstoverføringsprotokollen (HTTP), og fungerer i hovedsak ved å utstede tilgangspolletter til tredjepartsklienter via en autorisasjonsserver, gitt godkjenning fra ressurseieren. Tredjeparten kan så bruke polletten for å få tilgang til de beskyttede ressursene som er ligger på ressursserveren. OAuth 2.0 har egne autorisasjonsflyter for vevapplikasjoner, skrivebordsprogrammer, mobiltelefoner og smartutstyr.

OAuth er en autorisasjonsprotokoll og ikke en autentiseringsprotokoll. Bruk av OAuth som autentiseringsmetode kalles av og til for pseudo-autentisering.[]

* Autorisasjonsflyt uten OAuth: En hypotetisk autorisasjonsflyt hvor påloggingsinformasjon deles med en tredjepartsapplikasjon. Dette innebærer mange sikkerhetsrisikoer som kan forhindres ved bruk av OAuth-autorisasjonsflyter.Autorisasjonsflyt uten OAuth: En hypotetisk autorisasjonsflyt hvor påloggingsinformasjon deles med en tredjepartsapplikasjon. Dette innebærer mange sikkerhetsrisikoer som kan forhindres ved bruk av OAuth-autorisasjonsflyter.
* En høynivå-oversikt over en OAuth 2.0-autorisasjonsflyt: En oversikt over en OAuth 2.0-flyt på høyt nivå. Ressurseierens legitimasjon brukes bare på autorisasjonsserveren, men ikke på klienten (f.eks. tredjepartsapplikasjonen)En høynivå-oversikt over en OAuth 2.0-autorisasjonsflyt: En oversikt over en OAuth 2.0-flyt på høyt nivå. Ressurseierens legitimasjon brukes bare på autorisasjonsserveren, men ikke på klienten (f.eks. tredjepartsapplikasjonen)

Historie
--------

OAuth-logoen, designet av den amerikansk bloggeren Chris Messina
Starten på OAuth kan spores tilbake til 2006 i november da Blaine Cook utviklet Twitter sin implementasjon av OpenID. På samme tid trengte nettsiden Mamma.gnolia en løsning som gjorde at brukerne deres kunne bruke OpenID for å autorisere skjermelementer (*widgets*), i instrumentpanelet på datamaskinene deres, slik at disse kunne få tilgang til tjenesten. Blaine Cook, Chris Messina og Larry Halff fra Magnolia møtte David Recordon for å diskutere bruk av OpenID for delegert godkjenning med Twitter og Magnolia sine API-er. De konkluderte med at det ikke fantes noen åpne standarder for tilgangsdelegasjon med API.

I 2007 april ble det opprettet en OAuth-diskusjonsgruppe for å skrive et forslag til en åpen protokoll. Dewitt Clinton fra Google uttrykte interesse for å bidra. I 2007 juli hadde gruppen laget et utkast. Eran Hammer ble også med, og koordinerte mange av bidragene slik at man fikk en mer formell spesifikasjon. I 2007 desember ble det endelige utkastet til OAuth Core 1.0 utgitt.

I 2008 november på det 73. Internet Engineering Task Force (IETF) -møtet i Minneapolis ble det avholdt en *Birds of a Feather*-økt (BoF) for OAuth hvor man diskuterte hvorvidt protokollen skulle tas inn i IETF for videre standardiseringsarbeid. Arrangementet hadde stort oppmøte, og det var bred støtte for å danne en OAuth-arbeidsgruppe innenfor IETF.

I 2010 april ble OAuth 1.0-protokollen publisert som RFC 5849. Siden 2010 august 31 har alle tredjeparts Twitter-applikasjoner blitt pålagt å bruke OAuth.

OAuth 2.0-rammeverket ble publisert med hensyn på ytterligere brukstilfeller og utvidelseskrav hentet inn bredt fra IETF-fellesskapet. Selv om 2.0-rammeverket riktignok er bygget på erfaringer fra OAuth 1.0, så er ikke OAuth 2.0 bakoverkompatibel med OAuth 1.0. OAuth 2.0 ble publisert som RFC 6749, mens bruken av bærepollett (*bearer token*) ble publisert som RFC 6750.

OAuth 2.1 autorisasjonsrammeverket er under utarbeidelse, og skal konsoliderere funksjonaliteten i OAuth 2.0, OAuth 2.0 for *native-*applikasjoner, bevisnøkkel for kodeutveksling (PKCE), OAuth 2.0 for nettleserbaserte applikasjoner, OAuth Security-mønsterpraksis og bruk av bærepollett.

Referanser
----------

1. ↑  «Open Authorization - Glossary | CSRC».
2. 1 2  Hardt, Dick. «RFC6749 - The OAuth 2.0 Authorization Framework». Internet Engineering Task Force. Arkivert fra originalen 15. oktober 2012. Besøkt 10. oktober 2012.
3. ↑  Whitson, Gordon. «Understanding OAuth: What Happens When You Log Into a Site with Google, Twitter, or Facebook». Arkivert fra originalen 24. april 2014. Besøkt 15. mai 2016.
4. ↑  «Amazon & OAuth 2.0». Arkivert fra originalen 8. desember 2017. Besøkt 15. desember 2017.
5. ↑  «Introduction». Arkivert fra originalen 21. november 2018. Besøkt 21. november 2018.
6. ↑  «OAuth Core 1.0». Arkivert fra originalen 25. november 2015. Besøkt 16. oktober 2014.
7. ↑  Chris Crum. «Twitter Apps Go OAuth Today». Arkivert fra originalen 31. juli 2017. Besøkt 31. juli 2017.
8. ↑  Lodderstedt, Torsten. «The OAuth 2.1 Authorization Framework». Besøkt 22. november 2020.