OAuth is een authenticatieprotocol waarmee applicaties namens een gebruiker beperkte toegang krijgen tot API's. OAuth vraagt, in tegenstelling tot OpenID, niet aan de gebruiker om zijn gegevens, maar geeft een applicatie op verzoek gelimiteerde toegangsrechten tot een API via een OAuth Token. De applicatie kan dan de identiteit van de gebruiker bevestigd krijgen door het gebruik van de API. De gebruiker geeft de rechten aan de token om namens hem toegang te krijgen tot de API, van bijvoorbeeld netwerksite Facebook of berichtendienst Twitter.

Klik voor groot

OAuth bestaat al bijna vijf jaar maar werd tot twee jaar geleden nog niet veel gebruikt. Het protocol ontstond vanwege de behoefte aan een open standaard om authenticatie van gebruikers te versimpelen. Veelal werd teruggevallen op OpenID, maar daarin werden tekortkomingen geconstateerd als het ging in de authenticatie van API's.

Toegang tot API's gezocht

De ontwikkeling van OAuth begon toen enkele ontwikkelaars zochten naar manieren om toegang tot de API's van Twitter en het voormalige social bookmarkingplatform Ma.gnolia te delegeren aan een authenticatie protocol. In eerste instantie werd de oplossing gezocht in OpenID, maar al snel werd dat idee verlaten.

In 2007 werd een discussiegroep opgericht dat vorm gaf aan OAuth en de eerste complete OAuth Core werd in oktober 2007 gepresenteerd. Een jaar later werd OAuth verder gestandaardiseerd in de Internet Engineering Task Force, waarna in april 2010 het OAuth 1.0 Protocol werd gepubliceerd.

De adoptie van OAuth ging snel toen in augustus 2010 alle applicaties van derden die wilden aansluiten op Twitter de verplichting kregen OAuth te gebruiken en zich te identificeren bij aanmelding bij de berichtendienst. Flickr, LinkedIn, MySpace, Netflix, Tumblr, Vimeo, Yahoo en Yelp volgden.

Protocol moest simpeler

Ondertussen werd OAuth verder ontwikkeld en meer toegesneden op de wensen van de bedrijven die ermee wilden werken. Het protocol moet simpeler worden om mee te werken voor ontwikkelaars op clientplatforms en de authenticatie werd uitgebreid naar zowel webapplicaties, desktopapplicaties en mobiele telefoons. De nieuwe standaard, OAuth 2.0 die niet backward compatible is met OAuth 1.0, is omarmd door Facebook, Foursquare, Microsoft en Google.

Direct barstte de discussie los over de veiligheid van de nieuwe standaard. Daarbij ging het met name om de manier waarop de API-houders omgaan met de Token, de valid key. Eran Hammer, die inmiddels niets meer met OAuth te maken wil hebben, was daar al tijdens zijn werk aan het project heel open in. Hammer uitte zijn eerste kritiek al in 2010 en vond dat het laten vallen van de versleuteling die wel in 1.0 zat “onvergeeflijk". Ook werd het gebruik van signatures geschrapt omdat ontwikkelaars daar veel moeite mee hadden in OAuth 1.0. Er werd meer vertrouwen gelegd in HTTPS om afluisteren te voorkomen, maar dat vond Hammer een lachertje.

Lees verder op pagina 2 over HTTPS

HTTPS een optie

Doordat het gebruik van HTTPS een optie werd en geen vereiste, vond hij dat de token die werd verstuurd tussen API en applicatie te veel open kwam te liggen. In combinatie met het ontbreken van een versleuteling van de token, werd het systeem kwetsbaar. Het enige dat een aanvaller hoeft te doen is de hand leggen op die token en zo toegang te krijgen via de sleutel tot de API.

Daarmee, zo zegt Hammer, wordt OAuth het zwakste punt in de beveiligde communicatie tussen API's en applicaties en naarmate OAuth meer wordt gebruikt voor meer doeleinden, wordt een aanval erop aantrekkelijker. Aangezien aanvallers altijd gaan voor het zwakste punt, zouden bedrijven die dergelijke authenticatie vereisen, niet meer investeren in zwaardere beveiligingsmechanismen op ander plekken.

In de toekomst een probleem

Nu nog zou het gebruik van OAuth 2.0 redelijk veilig zijn doordat slechts een aantal bedrijven OAuth gebruiken en dan ook nog voor specifieke doeleinden en voor specifieke applicaties. De aandacht die de implementatie van OAuth krijgt is daardoor groot en dus ook de aandacht voor de beveiligde omgeving waarin het wordt gebruikt. Daardoor wordt de Token niet gebruikt voor authenticatie van de gebruiker door een minder bekende en mogelijk onbetrouwbare website, die zo de token afvangt.

Maar als er meer interoperable API's worden gebruikt voor het verbinden van webdiensten, zal OAuth 2.0 de mist in gaan, zegt Hammer. De gebruiker weet dan niet altijd of de dienst waarmee hij contact maakt te vertrouwen is en omdat de connectie wel beveiligd is maar de token zelf niet versleuteld, blijft de autorisatie kwetsbaar.

Is de server wel te vertrouwen?

“Een server kan ssl gebruiken en ook nog eens aan de klantzijde vragen om een OAuth toegangstoken dat is afgegeven door Google", zegt Hammer. “Maar die server kan niets te maken hebben met Google. De gebruiker moet dan zelf bedenken of de vragende server wel geautoriseerd is om Googles toegangstoken te zien."

Hammer vergelijkt het met het gebruik van cookies. “Cookies hebben regels over welke cookie gedeeld mag worden met welke server. Maar die regels worden meegegeven van de zijde van de gebruiker en daarom heeft het gebruik van cookies een lange geschiedenis van beveiligingsproblemen doordat cookies verkeerd werden gedeeld. Dat geldt ook voor OAuth 2.0. Elke oplossing die aan de gebruikerskant vraagt om naleving en bepaling van beveiligingsregels zal falen."