Hoppa till innehållet

OAuth

Från Wikipedia
OAuth
Teknisk standard
Oauth logo.svg
Inofficiell logo
TypÖppen standard
AnvändningsområdeAuktorisering
SpecifikationRFC 6749
Utvecklades2006–2012
AntogsOktober 2012
Ansvarigt organIETF
StatusAnvänds
ImplementationerFacebook, Google, Twitter mfl.

OAuth (förkortning för Open Authorization) är en öppen standard för att dela med sig av viss information eller vissa funktioner hos en webbplats eller annan tjänst till en tredje part utan att behöva dela med sig av sitt lösenord.[1][2][3]

Standarden är konstruerad för att auktorisera tredje parter för specifika ändamål men används i praktiken ofta för att låta en tredje part sköta inloggning till hela kontot (t.ex. "Logga in med Google"). Då används OAuth för autentisering snarare än auktorisering, och fungerar därmed som ersättare för den äldre standarden OpenID.[4] OAuth används av företag såsom Amazon, Google, Facebook, Microsoft och Twitter för att låta användare ge externa tjänster rätt att interagera med deras användarkonton och data på olika sätt.[5]

OAuth version 2.0 är (2023) en de facto industristandard för auktorisering. OAuth 2.0 tillhandahåller specifika auktorisationsmekanismer för tredje parter såsom webbapplikationer, stationära applikationer, mobiltelefoner och hushållsföremål i smarta hem. Specifikationen och dess tillägg utvecklas av OAuth Working Group inom IETF.[2]

IETF har kritiserats för att ha gjort standarden överdrivet komplicerad i syfte att skapa en onödig marknad för IT-företag som säljer integrationslösningar och konsulttjänster.[6]

Funktion

[redigera | redigera wikitext]

Innan autentisering och auktorisering med OAuth existerade krävdes det vanligen att man angav sitt användarnamn och lösenord i ett formulär, till exempel inloggningsskärmen för Gmail, för att komma åt personlig data såsom sina mejl. Om en tredje person (eller programvara) skulle få tillgång till ens mejl behövde man dela med sig av sina inloggningsuppgifter.[7]

Eftersom alla inte är bekväma med att ge tillgång till all sin data på detta sätt fanns ett behov av att kunna ge begränsad tillgång istället. Man kanske vill ge en tredjepartstjänst åtkomst till sitt e-postkonto, men bara ge tjänsten rätt att läsa ens kontakter, inte att läsa ens e-post eller redigera ens kontakter.[7]

När man använder OAuth ger en åtkomstkod, som har en begränsad livslängd, en sådan begränsad åtkomst.[8] Man kan då på ett enklare sätt ansluta flera applikationer från tredje parter genom att ge dem åtkomstkoder. Det är också säkrare eftersom inloggningsuppgifterna inte måste delas med andra.[7]

Användningsfall

[redigera | redigera wikitext]

Typiskt sett låter OAuth-protokollet en användare ge en klient (t.ex. en tredjepartsapplikation) säker delegerad åtkomst till användarens eget innehåll på en server. Protokollet specificerar en rutin för hur användare kan auktorisera tredjepartsåtkomst till sitt innehåll på en server utan att dela med sig av inloggningsinformation.[9][8]

Då OAuth är specifikt designat för att användas med webbprotkollet HTTP fungerar det i praktiken genom att en auktoriseringsserver utfärdar en åtkomstkod (token) till en tredjepartsklient efter att användaren som äger innehållet har godkänt detta. Den tredje parten använder sedan åtkomstkoden för att komma åt användarens innehåll på innehållsservern.[10]

Authorization flow without Oauth.
En hypotetisk auktoriseringsrutin (på engelska) där inloggningsinformation delas med en tredjepartsapplikation. Detta innebär många säkerhetsrisker som kan förhindras genom att använda OAuth.
A high-level overview of Oauth 2.0 authorization flow.
En översikt (på engelska) över en auktoriseringsrutin enligt oAuth 2.0-flödet på hög nivå. Användarens ("resursägarens") inloggningsinformation används endast av användaren, men inte av tredjepartsapplikationen.

För att tredjepartsapplikationen (till exempel en app i en mobiltelefon) inte ska kunna läsa av användarens användarnamn och lösenord är det lämpligt att inte låta användaren logga in på OAuth-servern och tilldela appen rättigheter direkt inifrån appen.[7] Enligt riktlinjer från IETF bör användaren istället uppmanas att auktorisera appen genom sin vanliga webbläsare.[9] Det medför även att användaren slipper logga in gång på gång, eftersom appen kan öppna mobilens webbläsare (som redan kanske är inloggad) var på användaren kan tilldela appen adekvata rättigheter.[9]

Historia

[redigera | redigera wikitext]

OAuth uppstod i november 2006 när Blaine Cook vidareutvecklade Twitters implementation av OpenID. Samtidigt behövde Magnolias en lösning för att tillåta sina medlemmar med OpenID att ge vissa externa funktioner åtkomst till deras tjänster. Bolagen kom fram till att de behövde en delegerad autentisering med Twitters OpenID för Magnolias API:er, och drog slutsatsen att det inte fanns några öppna standarder för API-åtkomstdelegering vid denna tid.[11]

En diskussionsgrupp för OAuth skapades i april 2007 och utvecklare från Google fick då reda på OAuth-projektet och uttryckte sitt intresse för att stödja det. I juli 2007 utarbetade teamet en första specifikation. Den 4 december 2007 släpptes det slutgiltiga utkastet för OAuth Core 1.0.[12]

I november 2008 sammanträdde Internet Engineering Task Force i Minneapolis och diskuterade införandet av protokollet i IETF för vidare standardisering. Evenemanget var välbesökt och det fanns ett brett stöd för att formellt skapa en OAuth-arbetsgrupp inom IETF.

OAuth 1.0 publicerades som RFC 5849, en informativ RFC, i april 2010. Sedan den 31 augusti 2010 har alla Twitter-applikationer från tredje part varit skyldiga att använda OAuth.[13]

OAuth 2.0-ramverket togs fram för att passa fler användningsscenarion och tillgodose olika krav på utökningsmöjligheter som samlats in genom IETF-förfarandet. Även om OAuth 2.0 bygger på erfarenheterna från OAuth 1.0 är den andra versionen inte bakåtkompatibel med den första. I oktober 2012 publicerades OAuth 2.0 som RFC 6749 och rutinen för så kallat Bearer Token Usage som RFC 6750.

OAuth 2.1 är ett pågående försök att konsolidera OAuth 2.0 och många vanliga tillägg under ett nytt namn.

OAuth 2.1 befinner sig på utkaststadiet och sammanför funktionaliteten i RFC:erna OAuth 2.0, OAuth 2.0 for Native Apps, Proof Key for Code Exchange, OAuth 2.0 för webbläsarbaserade appar, OAuth Security Best Current och Bearer Token Usage.[9]

Säkerhet

[redigera | redigera wikitext]

OAuth 1.0

[redigera | redigera wikitext]

Den 23 april 2009 tillkännagavs ett säkerhetsfel för sessionsfixering i 1.0-protokollet. Det påverkar OAuth-auktoriseringsrutinen (även känd som "3-legged OAuth").[14] Version 1.0a av OAuth Core-protokollet utfärdades för att lösa detta problem.[15]

OAuth 2.0

[redigera | redigera wikitext]

I januari 2013 publicerade Internet Engineering Task Force en angreppsmodell för OAuth 2.0.[16] Bland de hot som beskrivs finns ett som kallas "Open Redirector"; i början av 2014 beskrevs en variant av detta under namnet "Covert Redirect" av Wang Jing.[17][18][19]

OAuth 2.0 har analyserats enligt formell webbprotokollanalys. Denna analys avslöjade att i konfigurationer med flera auktoriseringsservrar – varav en beter sig illasinnat – kan klienter bli bortkollrade av auktoriseringsservern så att de börjar vidarebefordra hemligheter till den illasinnade auktoriseringsservern (så kallad AS Mix-Up Attack).[20] Detta föranledde skapandet av ett nytt utkast riktlinjer som syftar till att definiera en ny säkerhetsstandard för OAuth 2.0.[21]

En implementation av OAuth 2.0 med många säkerhetsbrister har avslöjats.[22]

I april och maj 2017 drabbades cirka en miljon Gmail-användare av en OAuth-baserad attack, och fick ett e-postmeddelande som utgavs vara från en kollega, arbetsgivare eller vän som ville dela ett dokument på Google Docs.[23] De som klickade på länken i e-postmeddelandet uppmanades att logga in och tillåta att ett potentiellt illasinnat tredjepartsprogram som heter "Google Apps" skulle få komma åt deras "e-postkonto, kontakter och onlinedokument".[23] Inom "ungefär en timme" stoppades attacken av Google, som rådde de som hade gett "Google Apps" åtkomst till sin e-post att återkalla sådan åtkomst och ändra sina lösenord.[23]

OAuth 2.1

[redigera | redigera wikitext]

I utkastet till OAuth 2.1 har användningen av PKCE-tillägget för inbyggda appar rekommenderats för alla typer av OAuth-klienter, inklusive webbapplikationer. Detta för att undvika att illasinnade webbläsartillägg utför kodinjektionsattacker.[24]

Tilldelningssätt

[redigera | redigera wikitext]

OAuth-ramverket specificerar flera sätt att ge tillgång till innehåll och resurser, kallade OAuth grants, eller tilldelningssätt, som passar olika bra beroende på användningsscenario. Några av de vanligaste tilldelningssätten är:[25]

  • Med auktoriseringskod (Authorization Code grant)
  • Implicit tilldelning (Implicit grant)
  • Lösenordsbaserad tilldelning (Resource Owner’s Password Credentials grant)
  • Klientbaserad tilldelning (Client Credentials grant)
  • Enhetsbaserad tilldelning (Device grant)[8]

Tilldelning med auktoriseringskod

[redigera | redigera wikitext]

Att använda en auktoriseringskod är det vanligaste och säkraste tilldelningssättet när en användare är involverad. Det sker genom att tredjepartsapplikationen skickar användaren till en speciell webbplats (t.ex. Facebook, Google) för att godkänna tilldelningen.[25]

I RFC:n kallas webbplatsen där användaren gör detta för "auktoriseringspunkt" (Authorize endpoint) och det är vanligtvis samma webbplats som används när man loggar in eller registrerar sig på tjänsten.[8]

När användaren godkänt tilldelningen skapas en auktoriseringskod (Authorization code), som är en slumpmässig ASCII-text som användaren får med sig när han eller hon skickas tillbaka till tredjepartsapplikationen efter en lyckad inloggning på OAuth-servern.[8]

Tredjepartsapplikationen kontaktar OAuth-servern igen och byter auktoriseringskoden mot en åtkomstkod (token) som ger tillgång till beviljade resurser.[8]

PKCE

[redigera | redigera wikitext]

När användaren skickas tillbaka till tredjepartsapplikationen görs det ofta rent tekniskt genom en så kallad HTTP Redirect som kan se ut så här:

HTTP/1.1 302 Found
Location: https://min-app.se/redirect?code=g0ZxMzE2[26]

Parametern "code" innehåller auktoriseringskoden i klartext vilket innebär att en angripare som har tagit över användarens webbläsare potentiellt kan stjäla den och sedan använda den för att få tillgång till det som tilldelats applikationen.[7]

För att råda bot på detta kan applikationen implementera standarden PKCE. Då genererar applikationen först en hemlig text som kallas för kodverifierare (code verifier) och som den skickar med användaren till OAuth-servern i hashat format (SHA-256) när användaren auktoriserar applikationen.[7]

OAuth-servern kommer att spara hashen och när applikationen sedan anropar OAuth-servern igen för att få ut sin åtkomstkod skickar den även med den hemliga texten i icke-hashat format. OAuth-servern kommer att hasha texten och bara returnera en tillgångskod om hashen stämmer med den hash som användaren angav i samband med att applikationen auktoriserades av användaren. Eftersom detta anrop sker via HTTPS i bakgrunden exponeras aldrig den icke-hashade kodverifieraren för användarens webbläsare, och PKCE skyddar därmed mot sårbarheter i webbläsaren.[7]

Implementationer

[redigera | redigera wikitext]

Facebook stöder endast OAuth 2.0.[27] Google stöder OAuth 2.0 som den rekommenderade auktoriseringsmekanismen för alla dess API:er. Microsoft stöder även OAuth 2.0 för olika API:er och dess Azure Active Directory-tjänst som används för att säkra många Microsoft och tredje parts API:er.[28][29][27]

OAuth kan användas för att skydda RSS/Atom-flöden. Tillgång till RSS/Atom-flöden som kräver autentisering har alltid varit ett problem. Till exempel kunde ett RSS-flöde från en säker Google-webbplats inte nås med Google Reader. Istället skulle three-legged OAuth ha använts för att ge den RSS-klienten åtkomst till flödet från Googles webbplats.[30]

OAuth och andra standarder

[redigera | redigera wikitext]

OAuth är en egen tjänst och ska inte sammanblandas med OpenID, som är en egen arkitektur. OAuth är inte heller relaterat till OATH, som är en referensarkitektur för autentisering, inte en standard för auktorisering. OAuth är dock direkt relaterat till OpenID Connect (OIDC), eftersom OIDC är ett autentiseringslager byggt ovanpå OAuth 2.0. OAuth är inte heller relaterat till XACML, som är en auktoriseringspolicystandard. OAuth kan användas tillsammans med XACML, där OAuth används för äganderättsmedgivande och åtkomstdelegering medan XACML används för att definiera auktoriseringspolicyerna (t.ex. att chefer ska kunna se dokument i sin region etc).[31]

OpenID jämfört med pseudo-autentisering med OAuth

[redigera | redigera wikitext]

OAuth är ett auktoriseringsprotokoll snarare än ett autentiseringsprotokoll, eftersom det är designat för att ge identifierade klienter rätt till visst innehåll men inte att i sig sköta identifieringen av klienten. Att använda OAuth självständigt som en autentiseringsmetod kan kallas pseudoautentisering.Följande diagram visar skillnaderna mellan att använda OpenID (specifikt utformat som ett autentiseringsprotokoll) och OAuth för auktorisering.[31][30]

Kommunikationsflödet i båda processerna är liknande:[31][7]

  1. Användaren begär en resurs- eller webbplatsinloggning från applikationen.
  2. Webbplatsen ser att användaren inte är autentiserad. Den formulerar en begäran till identitetsleverantören, kodar den och skickar den till användaren som en del av en omdirigerings-URL.
  3. Användarens webbläsare gör en begäran till omdirigeringsadressen för identitetsleverantören (den inkluderar här applikationens begäran).
  4. Vid behov autentiserar identitetsleverantören användaren (kanske genom att be användaren om dennes användarnamn och lösenord).
  5. När identitetsleverantören säkerställt att användaren är autentiserad behandlar den applikationens begäran, formulerar ett svar och skickar det tillbaka till användaren tillsammans med en omdirigerings-URL som tar användaren tillbaka till applikationen.
  6. Användarens webbläsare går till omdirigeringsadressen och kommer tillbaka till applikationen (identitetsleverantörens svar inkluderas i anropet).
  7. Applikationen avkodar identitetsleverantörens svar och fortsätter därefter.
  8. (endast OAuth) Svaret inkluderar en åtkomstkod som applikationen kan använda för att få direkt åtkomst till identitetsleverantörens tjänster för användarens räkning.[7]

Den avgörande skillnaden är att i fallet med OpenID:s autentisering är svaret från identitetsleverantören ett tillstyrkande av identitet; medan identitetsleverantören också en API- leverantör i användningsfallet för auktorisering med OAuth, varför svaret från identitetsleverantören är en åtkomstkod som kan ge applikationen löpande åtkomst till några av identitetsleverantörens API:er för användarens räkning. Åtkomstkoden fungerar som en slags "extranyckel" som applikationen kan skicka med sina förfrågningar till identitetsleverantören, och som bevisar att den har tillstånd från användaren att komma åt dessa API:er.[7]

Eftersom identitetsleverantören vanligtvis (men inte alltid) autentiserar användaren som en del av processen för att bevilja en OAuth-åtkomstkod, är det frestande att se en framgångsrik begäran om OAuth-åtkomstkod som en autentiseringsmetod i sig. Men eftersom OAuth inte utformades med denna sorts användning i åtanke kan ett sådant antagande leda till stora säkerhetsproblem.[32]

OpenID vs. pseudo-authentication using OAuth

OAuth och XACML

[redigera | redigera wikitext]

XACML är ett policybaserat, attributbaserat behörighetsramverk för åtkomstkontroll.[30] Det ger:

  • En arkitektur för accesskontroll.
  • Ett policyspråk för att formulera ett brett utbud av åtkomstkontrollpolicyer inklusive policyer som kan använda samtycken som hanteras/definieras via OAuth.
  • Ett förfrågnings-/svarsschema för att skicka och ta emot auktoriseringsförfrågningar.

XACML och OAuth kan kombineras för att ge ett mer omfattande tillvägagångssätt för auktorisering. OAuth tillhandahåller inget språk för att definiera en policy för åtkomstkontroll. XACML kan istället användas som policyspråk för detta ändamål.[31][30]

Medan OAuth sköter delegerad åtkomst ("jag [användaren] ger Twitter åtkomst till mitt Facebook-flöde") och identitetsbaserad auktorisering, använder XACML en attributbaserad strategi som kan ta hänsyn till vilka attribut användaren har, vilken åtgärd som begärts, vilken resurs som åtgärden avser och i vilket sammanhang begäran sker (vem, vad, var, när, hur?). Med XACML är det möjligt att definiera policyer som t.ex[30]

  • Chefer kan se dokument på sin avdelning
  • Användare kan redigera dokument som de äger så länge de är utkast

XACML ger en mer detaljerad åtkomstkontroll än OAuth. OAuth är begränsat till att styra till gången till en ganska grov indelning (i så kallade scopes) av resurser på den efterfrågade tjänsten. Därför är det ofta meningsfullt att kombinera OAuth och XACML och låta OAuth tillhandahålla delegerad åtkomst och samtyckeshantering medan man låter XACML ta hand om auktoriseringspolicyer för applikationer, processer och data.[30]

Slutligen kan XACML fungera transparent över flera stackar (API:er, webb-SSO:er, ESB:er, egenutvecklade appar, databaser mm). OAuth fokuserar uteslutande på HTTP-baserade appar.[30]

Kontroverser

[redigera | redigera wikitext]

Utvecklaren Eran Hammer sa upp sig från sin roll som huvudutvecklare för OAuth 2.0-projektet, drog sig ur IETF:s arbetsgrupp och tog bort sitt namn från specifikationen i juli 2012. Som orsak uppgav Hammer en konflikt mellan webb- och företagskulturer och kritiserade IETF för att "bara bry sig om storföretagens användningsbehov" och att "inte behärska enkelhet".[6]

"Det som nu erbjuds är en plan för ett auktoriseringsprotokoll", skrev han, "som passar storföretag" och som skapar en "helt ny marknad för att sälja konsulttjänster och integrationslösningar".[6] När han jämförde OAuth 2.0 med OAuth 1.0 sade han att protokollet har blivit "mer komplext, mindre interopererbart, mindre användbart, mer ofullständigt och – viktigast av allt – mindre säkert". Han förklarade hur arkitekturförändringar i 2.0 gjorde åtkomstkoderna obundna i förhållande till klienterna, tog bort alla signaturer och kryptografi på protokollnivå och lade till tillfälliga åtkomstkoder (eftersom åtkomstkoder inte kunde återkallas) samtidigt som det krånglade till auktoriseringsförfarandet. Många artiklar lämnades ospecificerade eller obegränsade i specifikationen eftersom "arbetsgruppens natur har varit sådan att ingen fråga är för liten för att fastna i eller lämna öppen för varje implementation att besluta om själv."[6]

Utvecklaren David Recordon tog senare också bort sitt namn från specifikationerna av ospecificerade skäl. Dick Hardt tog över redaktörsrollen och ramverket publicerades i oktober 2012.

David Harris, författare till e-postklienten Pegasus Mail, har kritiserat OAuth 2.0 för att vara "rena rama hundmaten" och för att kräva att man skriver anpassade moduler specifikt för varje tjänst (Gmail, Microsoft Mail-tjänster, etc.) för att protokollet ska fungera.[33]

Se även

[redigera | redigera wikitext]

Referenser

[redigera | redigera wikitext]
  1. ^ ”Open Authorization - Glossary | CSRC”. csrc.nist.gov. https://csrc.nist.gov/glossary/term/open_authorization. 
  2. ^ [a b] RFC6749 - The OAuth 2.0 Authorization Framework. https://tools.ietf.org/html/rfc6749. 
  3. ^ ”Understanding OAuth: What Happens When You Log Into a Site with Google, Twitter, or Facebook”. Lifehacker. http://lifehacker.com/5918086/understanding-oauth-what-happens-when-you-log-into-a-site-with-google-twitter-or-facebook. 
  4. ^ Justin Richer on OAuth. https://ieeexplore.ieee.org/document/8938121. 
  5. ^ ”Amazon & OAuth 2.0”. Amazon & OAuth 2.0. https://login.amazon.com/. 
  6. ^ [a b c d] Hammer, Eran (28 July 2012). ”OAuth 2.0 and the Road to Hell”. Hueniverse. https://hueniverse.com/oauth-2-0-and-the-road-to-hell-8eec45921529. 
  7. ^ [a b c d e f g h i j] ”Modern Guide - What is OAuth 2.0 and How Does It Work?” (på engelska). FusionAuth. https://fusionauth.io/articles/oauth/modern-guide-to-oauth. Läst 31 december 2023. 
  8. ^ [a b c d e f] Hardt, Dick (2012-10). RFC 6749; The OAuth 2.0 Authorization Framework. https://datatracker.ietf.org/doc/rfc6749/. Läst 31 december 2023. 
  9. ^ [a b c d] OAuth 2.0 for Native Apps, Best Current Practice. RFC 8252 s. 1
  10. ^ Hardt, Dick (October 2012). RFC6749 - The OAuth 2.0 Authorization Framework. Internet Engineering Task Force. doi:10.17487/RFC6749. https://tools.ietf.org/html/rfc6749. Läst 10 oktober 2012. 
  11. ^ ”Introduction”. oauth.net. https://oauth.net/about/introduction/. 
  12. ^ ”OAuth Core 1.0”. OAuth Core 1.0. 4 December 2007. http://oauth.net/core/1.0/. 
  13. ^ Chris Crum (31 August 2010). ”Twitter Apps Go OAuth Today”. WebProNews.com. http://www.webpronews.com/twitter-apps-go-oauth-today-2010-08/. 
  14. ^ ”OAuth Security Advisory: 2009.1”. oauth.net. 23 April 2009. http://oauth.net/advisories/2009-1. 
  15. ^ ”OAuth Core 1.0a”. oauth.net. http://oauth.net/core/1.0a. 
  16. ^ RFC6819 - OAuth 2.0 Threat Model and Security Considerations. January 2013. https://tools.ietf.org/html/rfc6819.html. Läst 29 juni 2020. [rfc:6819 OAuth 2.0 Threat Model and Security Considerations]. Internet Engineering Task Force. Accessed January 2015.
  17. ^ ”Serious security flaw in OAuth, OpenID discovered”. CNET. 2 May 2014. http://www.cnet.com/news/serious-security-flaw-in-oauth-and-openid-discovered/. 
  18. ^ ”Math student detects OAuth, OpenID security vulnerability”. Math student detects OAuth, OpenID security vulnerability. 3 May 2014. http://phys.org/news/2014-05-math-student-oauth-openid-vulnerability.html. 
  19. ^ ”Covert Redirect”. Covert Redirect. 1 May 2014. http://tetraph.com/covert_redirect/.  Arkiverad 10 mars 2016 hämtat från the Wayback Machine.
  20. ^ Fett, Daniel; Küsters, Ralf; Schmitz, Guido (2016). ”A Comprehensive Formal Security Analysis of OAuth 2.0”. Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security. New York, New York, USA: ACM Press. Sid. 1204–1215. doi:10.1145/2976749.2978385. ISBN 9781450341394. Bibcode: 2016arXiv160101229F. 
  21. ^ Bradley, John; Labunets, Andrey; Lodderstedt, Torsten. OAuth 2.0 Security Best Current Practice. 
  22. ^ ”Hacking Facebook with OAuth 2.0 and Chrome”. Hacking Facebook with OAuth 2.0 and Chrome. 12 February 2013. http://homakov.blogspot.co.uk/2013/02/hacking-facebook-with-oauth2-and-chrome.html. 
  23. ^ [a b c] ”Google Docs phishing email 'cost Minnesota $90,000'”. BBC News. 8 May 2017. https://www.bbc.co.uk/news/technology-39845545. 
  24. ^ The OAuth 2.1 Authorization Framework. 13 October 2012. https://tools.ietf.org/html/draft-ietf-oauth-v2-1-00.html. Läst 22 november 2020. 
  25. ^ [a b] ”Oauth Grant Types”. Oauth Grant Types. https://oauth.net/2/grant-types/. 
  26. ^ ”The Authorization Response”. https://www.oauth.com/oauth2-servers/authorization/the-authorization-response/. 
  27. ^ [a b] ”Authentication - Facebook Developers”. Facebook for Developers. https://developers.facebook.com/docs/authentication/. 
  28. ^ ”v2.0 Protocols - OAuth 2.0 Authorization Code Flow”. Microsoft Docs. https://docs.microsoft.com/en-us/azure/active-directory/active-directory-v2-protocols-oauth-code. 
  29. ^ ”Using OAuth 2.0 to Access Google APIs | Google Identity Platform”. Google Developers. https://developers.google.com/identity/protocols/OAuth2. 
  30. ^ [a b c d e f g] José Ferreira Pinto Basto (2014-12). ”Identity and Access Management”. Altice Whitepapers (Altice Labs). https://www.openlabs.com.br/content/WP-Information-Access-Control-Models.pdf. Läst 31 december 2023. 
  31. ^ [a b c d] Prasad Lakshan (19 maj 2023). ”OpenID vs. OAuth vs. SAML: Understanding the Key Differences” (på engelska). UCSC ISACA Student Group. https://medium.com/ucsc-isaca-student-group/openid-vs-oauth-vs-saml-understanding-the-key-differences-b060d5bc2487. Läst 31 december 2023. 
  32. ^ ”End User Authentication with OAuth 2.0”. oauth.net. http://oauth.net/articles/authentication/. 
  33. ^ Harris, David (October 2021). ”Pegasus Mail and Mercury Developer News”. Pegasus Mail. http://www.pmail.com/devnews.htm. 
Den här artikeln är helt eller delvis baserad på material från en Wikipedia.
Hämtad från ”https://sv.wikipedia.org/w/index.php?title=OAuth&oldid=55275280”