Share
In een wereld die gedomineerd wordt door sociale media, is het moeilijk om een clienttoepassing niet te vinden die je hebt gebruikt om toegang te krijgen tot beperkte bronnen op een andere server. Je hebt bijvoorbeeld een webtoepassing (zoals NY Times) gebruikt om een interessant nieuwsartikel op je Facebook-wall of tweet erover. Of misschien hebt u de iPhone-app van Quora gebruikt die toegang biedt tot uw Facebook- of Google+ profiel en kunt u de resultaten aanpassen op basis van uw profielgegevens, zoals het voorstellen om andere gebruikers toe te voegen / uit te nodigen voor Quora, op basis van uw vriendenlijst. De vraag is, hoe krijgen deze applicaties toegang tot uw Facebook-, Twitter- of Google+ accounts en hoe kunnen ze toegang krijgen tot uw vertrouwelijke gegevens? Voordat ze dit kunnen doen, moeten ze een of andere vorm van authenticatiereferenties en autorisatiesubsidies voor de bronserver presenteren.
OAuth wordt vaak omschreven als een valet-sleutel voor het web.
Nu zou het echt zijn niet cool om uw Facebook- of Google-inloggegevens te delen met een externe clienttoepassing die alleen over uw vrienden hoeft te weten, omdat deze niet alleen onbegrensde en ongewenste toegang tot uw account biedt, maar deze heeft ook de inherente zwakte verbonden aan wachtwoorden. Hier komt OAuth om de hoek kijken, omdat het een kader voor toegangsdelegatie / autorisatie schetst dat kan worden gebruikt zonder dat het nodig is om wachtwoorden te delen. Om deze reden wordt OAuth vaak omschreven als een valet-sleutel voor het web. Het kan worden gezien als een speciale sleutel die toegang biedt tot beperkte functies en voor een beperkte periode zonder volledige controle weg te geven, net zoals de valet-sleutel voor een auto de parkeerwachter toestaat om de auto over een korte afstand te besturen, blokkeren toegang tot de kofferbak en de mobiele telefoon aan boord.
OAuth is echter geen nieuw concept, maar een standaardisatie en gecombineerde wijsheid van vele gevestigde protocollen. Ook vermeldenswaard is dat OAuth niet alleen beperkt is tot sociale-mediatoepassingen, maar ook een gestandaardiseerde manier biedt om informatie veilig te delen tussen verschillende soorten toepassingen die hun API's blootstellen aan andere toepassingen. OAuth 2.0 heeft een compleet nieuw proza en is niet achterwaarts compatibel met zijn voorganger. Dat gezegd hebbende, zou het goed zijn om eerst een paar basiswoordenlijsten van OAuth2.0 te bespreken voordat je verder gaat met meer details.
OAuth 1.0's belangrijkste nadeel was de inherente complexiteit die nodig was om de specificatie te implementeren.
Eigenlijk niets! Twitter werkt nog steeds prima met OAuth 1.0 en is net begonnen met het ondersteunen van een klein deel van de 2.0-specificatie. OAuth 1.0 was een weloverwogen spec en het maakte de uitwisseling van geheime informatie veilig mogelijk zonder de overhead die werd opgelegd door SSL. De reden waarom we een opknapbeurt nodig hadden, was grotendeels gebaseerd op de complexiteit waarmee de spec werd geconfronteerd. Het volgende zijn enkele gebieden waarop OAuth 1.0 niet indruk kon maken:
Voordat het protocol wordt gestart, moet de client zich registreren bij de machtigingsserver door het clienttype, de omleidings-URL (waar deze naar de machtigingsserver moet omleiden nadat de broneigenaar de toegang verleent of weigert) en alle andere informatie die door de server is vereist, te verstrekken en op zijn beurt krijgt een client-id (client-ID) en client-secret (client_secret). Dit proces staat bekend als klantregistratie. Na registratie kan de client een van de volgende flows aannemen om met de server te communiceren.
OAuth 2.0 brengt vijf nieuwe flows naar de tafel en biedt ontwikkelaars de flexibiliteit om een van deze flows uit te voeren, afhankelijk van het type cliënt dat betrokken is:
Elke stroom in detail bespreken zou buiten het bestek van dit artikel vallen en ik raad het lezen van de specificatie voor diepgaande stroominformatie liever aan. Maar om een idee te krijgen van wat er gaande is, gaan we dieper in op een van de meest gebruikte en ondersteunde flows: The Web Server Flow.
Aangezien dit een op omleiding gebaseerde stroom is, moet de client in staat zijn om te communiceren met de user agent van de broneigenaar (die in de meeste gevallen een webbrowser is) en is daarom typisch geschikt voor een webapplicatie. Het onderstaande diagram is een overzicht in vogelvlucht van hoe de eindgebruiker (of de broneigenaar) de clienttoepassing (in dit geval webserver-gebaseerde applicatie) gebruikt voor authenticatie en autorisatie met de autorisatieserver om toegang te krijgen tot de beschermde bronnen door de bronserver.
De client initieert namens de broneigenaar de stroom door om te leiden naar het autorisatie-eindpunt met een parameter response_type als code, een client-ID, die wordt verkregen tijdens clientregistratie, een omleidings-URL, een aangevraagd bereik (optioneel) en een lokale status (indien aanwezig). Om een indruk te krijgen van hoe het werkt, ziet u hier een screenshot van hoe een typisch verzoek / reactie eruit zou zien:
Dit stelt de eigenaar van de bron gewoonlijk voor met een webinterface, waar de eigenaar kan verifiëren en controleren wat alle machtigingen zijn die de client-app namens de eigenaar mag gebruiken.
Ervan uitgaande dat de broneigenaar toegang verleent aan de client, stuurt de machtigingsserver de user-agent door naar de client met behulp van de eerder verstrekte omleidings-URL, samen met de autorisatiecode zoals weergegeven door de onderstaande reactie.
De klant dan posts naar een ander autorisatie-eindpunt en verzendt de autorisatiecode die is ontvangen in de eerdere stap, samen met de omleidings-URL, de client-ID en het geheim ervan, verkregen tijdens clientregistratie en een parameter grant_type moet worden ingesteld als Authorisatie Code.
De server valideert vervolgens de autorisatiecode en verifieert dat de omleidings-URL dezelfde is als in de vorige stap. Als dit lukt, antwoordt de server terug met een toegangstoken en optioneel een vernieuwingstoken.
De client kan nu de API's gebruiken die door de implementatie worden geleverd en kan de bronserver vragen om een beperkte resource door het toegangstoken door te geven in de autorisatiekop van de aanvraag. Een voorbeeld van een CURL-verzoek aan de Blogger API van Google om een blog te krijgen, gezien de ID, zou er als volgt uitzien:
$ curl https://www.googleapis.com/blogger/v3/blogs/5223788876950011016 -H 'Autorisatie: OAuth ya29.AHES6ZRTj1GNxAby81Es-p_YPWWNBAFRvBYVsYj2HZJfJHU'
Merk op dat we het toegangstoken als autorisatiekop in het verzoek hebben toegevoegd en ook aan het token zijn ontsnapt door het op te nemen in enkele aanhalingstekens, omdat het token speciale tekens kan bevatten. Onthoud dat ontsnappen aan het toegangstoken alleen nodig is bij het gebruik van krullen. Het resulteert in het verzenden van de volgende aanvraag:
De bronserver verifieert vervolgens de doorgegeven referenties (toegangstoken) en reageert, indien succesvol, met de gevraagde informatie.
Deze voorbeelden zijn afkomstig van OAuth2.0 Playground en zijn typerend voor hoe Google de specificaties implementeert. Verschillen kunnen worden waargenomen bij het proberen van dezelfde stroom met andere providers (zoals Facebook of Salesforce) en dit is waar interoperabiliteitsproblemen binnensluipen, die we een beetje later bespreken.
Hoewel niet vereist door de spec, maar meestal zijn de toegangstokens van korte duur en hebben ze een vervaltijd. Dus wanneer een toegangstoken is verlopen, verzendt de client het vernieuwingstoken naar de machtigingsserver, samen met diens client-ID en geheim, en een parameter grant_type als refresh_token.
De machtigingsserver antwoordt vervolgens terug met de nieuwe waarde voor het toegangstoken.
Hoewel er een mechanisme bestaat om het uitgegeven vernieuwingstoken in te trekken, maar normaal gesproken leeft het verversingstoken voor eeuwig en moet als een geheime waarde worden beschermd en behandeld.
Gegeven door de acceptatiegraad, is OAuth 2.0 absoluut een verbetering ten opzichte van zijn geheimzinnige voorganger. Voorbeelden van ontwikkelaarsgemeenschappen die haperen tijdens het implementeren van de handtekeningen van 1.0 zijn niet onbekend. OAuth 2.0 biedt ook verschillende nieuwe subsidietypen, die kunnen worden gebruikt om veel gebruiksmogelijkheden zoals native applicaties te ondersteunen, maar de USP van deze specificatie is de eenvoud ten opzichte van de vorige versie.
Er zijn een paar losse eindjes in de specificatie, omdat het er niet in slaagt om een paar vereiste componenten goed te definiëren of laat over aan de implementaties om te beslissen, zoals:
Losse uiteinden in de OAuth 2.0-specificatie zullen waarschijnlijk een breed scala aan niet-interoperabele implementaties produceren.
Het kostte IETF ongeveer 31 conceptversies en het ontslag van de hoofdauteur / ontwikkelaar Eran Hammer van de commissie om de specificatie uiteindelijk te publiceren. Eran leidde tot een controverse door de specificatie te noemen "een slecht protocol en een doodsgeval door duizend keer knippen". Volgens hem was het gebruik van bearer tokens (verzenden van tokens via SSL zonder ondertekening of andere verificatie) over de gebruiker van handtekeningen (of MAC-tokens), gebruikt in OAuth 1.0 om het verzoek te ondertekenen, een slechte zet en een resultaat van verdeling van interesses tussen het web en enterprise communities.
De specificatie laat zeker veel uitbreidingspunten open, resulterend in implementaties die hun eigen parameters introduceren, naast wat de specificatie al definieert, en zorgt ervoor dat implementaties van verschillende providers niet met elkaar kunnen samenwerken. Maar uitgaande van de populariteit en acceptatiegraad van dit framework, waarbij elke grote speler in de stad (Google, Twitter, Facebook, Salesforce, Foursquare, Github etc.) het implementeert en aanpast zoals het hen uitkomt, is OAuth alles behalve een mislukking . Elke webtoepassing die van plan is zijn API's aan andere webtoepassingen beschikbaar te stellen, moet in feite een vorm van verificatie en autorisatie ondersteunen en OAuth past hier de factuur.
Accentsconagua