Opmerking. vert.: Dit geweldige artikel van Okta legt op een eenvoudige en duidelijke manier uit hoe OAuth en OIDC (OpenID Connect) werken. Deze kennis zal nuttig zijn voor ontwikkelaars, systeembeheerders en zelfs "gewone gebruikers" van populaire webapplicaties, die hoogstwaarschijnlijk ook vertrouwelijke gegevens uitwisselen met andere diensten.
In het stenen tijdperk van internet was het delen van informatie tussen services eenvoudig. U gaf gewoon uw login en wachtwoord van de ene dienst aan de andere, zodat hij uw account invoerde en alle informatie ontving die hij nodig had.
"Geef me je bankrekening." “We beloven dat alles goed komt met het wachtwoord en geld. Dat is eerlijk, eerlijk!" *Hee hee*
Verschrikking! Niemand mag ooit van een gebruiker eisen dat hij een gebruikersnaam en wachtwoord deelt, referenties, met een andere dienst. Er is geen garantie dat de organisatie achter deze dienst de gegevens veilig zal bewaren en niet meer persoonlijke informatie zal verzamelen dan nodig is. Het klinkt misschien gek, maar sommige apps gebruiken deze praktijk nog steeds!
Tegenwoordig is er één standaard waarmee de ene dienst veilig gebruik kan maken van de gegevens van een andere. Helaas gebruiken dergelijke normen veel jargon en termen, wat hun begrip bemoeilijkt. Het doel van dit materiaal is om aan de hand van eenvoudige illustraties uit te leggen hoe ze werken (Denk je dat mijn tekeningen lijken op kinderbekladdingen? Ach ja!).
Overigens is deze gids ook beschikbaar in videoformaat:
Dames en heren, welkom: OAuth 2.0
is een beveiligingsstandaard waarmee een applicatie toestemming kan krijgen om toegang te krijgen tot informatie in een andere applicatie. Volgorde van stappen voor het verlenen van een vergunning [toestemming] (Of toestemming [toestemming]) vaak bellen autorisatie [autorisatie] of gedelegeerde machtiging [gedelegeerde autorisatie]. Met deze standaard staat u een applicatie toe om namens u gegevens te lezen of de functies van een andere applicatie te gebruiken zonder uw wachtwoord te geven. Klas!
Stel dat u een site ontdekt met de naam "Ongelukkige woordspeling van de dag" [Vreselijke woordspeling van de dag] en besloot zich erop te registreren om dagelijkse woordspelingen in de vorm van sms-berichten op de telefoon te ontvangen. Je vond de site erg leuk en je besloot hem met al je vrienden te delen. Iedereen houdt tenslotte van griezelige woordspelingen, toch?
“Ongelukkige woordspeling van de dag: gehoord over de man die de linkerhelft van zijn lichaam verloor? Nu heeft hij altijd gelijk!” (geschatte vertaling, omdat het origineel zijn eigen woordspeling heeft - ca. vert.)
Het is duidelijk dat schrijven naar elke persoon uit de contactenlijst geen optie is. En als je ook maar een klein beetje op mij lijkt, dan doe je er alles aan om onnodig werk te vermijden. Gelukkig kan Terrible Pun of the Day al je vrienden zelf uitnodigen! Om dit te doen, hoeft u alleen de toegang tot de e-mail van uw contacten te openen - de site zelf zal hen uitnodigingen sturen (OAuth-regels)!
“Iedereen houdt van woordspelingen! - Al ingelogd? “Wilt u de Terrible Pun of the Day-website toegang geven tot uw contactenlijst? - Bedankt! Vanaf nu sturen we elke dag herinneringen naar iedereen die je kent, tot het einde der tijden! Je bent de beste vriend!"
- Kies uw e-mailservice.
- Ga indien nodig naar de mailsite en log in op uw account.
- Geef Terrible Pun of the Day toestemming voor toegang tot je contacten.
- Keer terug naar de Terrible Pun of the Day-site.
Als u van gedachten verandert, bieden toepassingen die OAuth gebruiken ook een manier om de toegang in te trekken. Zodra u besluit dat u niet langer contacten wilt delen met Terrible Pun of the Day, kunt u naar de mailsite gaan en de pun-site verwijderen uit de lijst met geautoriseerde applicaties.
OAuth-stroom
We hebben zojuist doorgenomen wat gewoonlijk wordt genoemd stroom [stroom] OAuth. In ons voorbeeld bestaat deze stroom uit zichtbare stappen, maar ook uit meerdere onzichtbare stappen, waarin twee diensten een veilige uitwisseling van informatie overeenkomen. Het vorige Terrible Pun of the Day-voorbeeld gebruikt de meest gebruikelijke OAuth 2.0-stroom, ook wel de "autorisatiecode"-stroom genoemd. [stroom "autorisatiecode"].
Voordat we ingaan op de details van hoe OAuth werkt, laten we het hebben over de betekenis van enkele termen:
- Broneigenaar:
Jij bent het! U bezit uw inloggegevens, uw gegevens en beheert alle activiteiten die op uw accounts kunnen worden uitgevoerd. - CLIËNT:
Een applicatie (bijvoorbeeld de Terrible Pun of the Day-service) die toegang wil hebben tot of bepaalde acties wil uitvoeren namens Broneigenaar'. - autorisatie server:
De applicatie die het weet Broneigenaar'a en waarin u Broneigenaar'Ik heb al een account. - Bronserver:
Application Programming Interface (API) of dienst die CLIËNT namens wil gebruiken Broneigenaar'. - Omleidings-URI:
De koppeling die autorisatie server zal omleiden Broneigenaar'en na het verlenen van toestemming CLIËNT'bij. Het wordt ook wel de "Callback-URL" genoemd. - Type reactie:
Het type informatie dat naar verwachting zal worden ontvangen CLIËNT. De meest voorkomende Type reactie'ohm is de code, dat wil zeggen CLIËNT verwacht te ontvangen Authorisatie Code. - strekking:
Dit is een gedetailleerde beschrijving van de vereiste machtigingen CLIËNT'y, zoals toegang tot gegevens of het uitvoeren van bepaalde acties. - Toestemming:
autorisatie server beret Scopesaangevraagd CLIËNT'om, en vraagt Broneigenaar'a, is hij klaar om te voorzien CLIËNT'de juiste machtigingen hebben. - klant-ID:
Deze ID wordt gebruikt om te identificeren CLIËNT'een op autorisatie server'e. - Cliëntgeheim:
Dit is het wachtwoord dat alleen bekend is CLIËNT'u en autorisatie server'bij. Het stelt hen in staat om privé informatie te delen. - Authorisatie Code:
Tijdelijke code met een korte geldigheidsduur, welke CLIËNT biedt autorisatie server'y in ruil voor Toegangstoken. - Toegangstoken:
De sleutel waarmee de client zal communiceren Bronserverom. Een soort badge of sleutelkaart die zorgt voor CLIËNT'toestemming hebben om gegevens op te vragen of handelingen op uit te voeren Bronservernamens jou.
Noot: Soms zijn Authorization Server en Resource Server dezelfde server. In sommige gevallen kunnen dit echter verschillende servers zijn, ook al behoren ze niet tot dezelfde organisatie. De autorisatieserver kan bijvoorbeeld een service van derden zijn die wordt vertrouwd door de bronserver.
Nu we de kernconcepten van OAuth 2.0 hebben behandeld, gaan we terug naar ons voorbeeld en kijken we wat er gebeurt in de OAuth-stroom.
- Jij, Broneigenaar, je de Terrible Pun of the Day-service wilt aanbieden (CLIËNTy) toegang tot uw contacten zodat zij uitnodigingen kunnen sturen naar al uw vrienden.
- CLIËNT leidt de browser om naar de pagina autorisatie server'a en neem op in query klant-ID, Omleidings-URI, Type reactie en een of meer Scopes (machtigingen) het nodig heeft.
- autorisatie server verifieert u en vraagt indien nodig om een gebruikersnaam en wachtwoord.
- autorisatie server geeft een formulier weer Toestemming (bevestigingen) met een lijst van alle Scopesaangevraagd CLIËNTom. U gaat akkoord of weigert.
- autorisatie server leidt u door naar de site CLIËNT'een, gebruiken Omleidings-URI met Authorisatie Code (Authorisatie Code).
- CLIËNT communiceert rechtstreeks met autorisatie server'ohm (het omzeilen van de browser Broneigenaar'a) en veilig verzendt klant-ID, Cliëntgeheim и Authorisatie Code.
- autorisatie server controleert de gegevens en reageert met Toegangstoken'om (toegangstoken).
- Nu CLIËNT kan gebruiken Toegangstoken om een verzoek naar toe te sturen Bronserver om een lijst met contacten te krijgen.
Klant-ID en geheim
Lang voordat je Terrible Pun of the Day toestemming gaf om toegang te krijgen tot je contacten, hadden de client en de autorisatieserver een werkrelatie tot stand gebracht. De autorisatieserver genereerde de client-ID en het clientgeheim (ook wel App ID и App-geheim) en stuurde ze naar de klant voor verdere interactie binnen OAuth.
"- Hallo! Ik wil graag met je samenwerken! - Natuurlijk, geen probleem! Hier zijn uw klant-ID en geheim!”
De naam impliceert dat het Clientgeheim geheim moet worden gehouden, zodat alleen de Client en de Autorisatieserver het weten. Het is immers met zijn hulp dat de Autorisatieserver de waarheid van de Klant bevestigt.
Maar dat is nog niet alles... Welkom OpenID Connect!
OAuth 2.0 is alleen ontworpen voor autorisatie - om toegang te bieden tot gegevens en functies van de ene applicatie naar de andere. (OIDC) is een dunne laag bovenop OAuth 2.0 die de inlog- en profielgegevens toevoegt van de gebruiker die is ingelogd op het account. Het organiseren van een inlogsessie wordt vaak aangeduid als authenticatie [authenticatie], en informatie over de gebruiker die is ingelogd op het systeem (d.w.z. over Broneigenaar'e), — persoonlijke gegevens [identiteit]. Als de autorisatieserver OIDC ondersteunt, wordt dit soms aangeduid als verstrekker van persoonsgegevens [identiteitsprovider]omdat het voorziet CLIËNT'informatie over hebben Broneigenaar'e.
Met OpenID Connect Connect kunt u scenario's implementeren waarbij een enkele login in meerdere applicaties kan worden gebruikt - deze benadering wordt ook wel eenmalig inloggen (SSO). Een applicatie kan bijvoorbeeld SSO-integratie met sociale netwerken zoals Facebook of Twitter ondersteunen, waardoor gebruikers een account kunnen gebruiken dat ze al hebben en liever gebruiken.
De flow (flow) OpenID Connect ziet er hetzelfde uit als in het geval van OAuth. Het enige verschil is dat in het primaire verzoek het specifieke bereik wordt gebruikt openid, - A CLIËNT wordt uiteindelijk zo ToegangstokenEn ID-token.
Net als in de OAuth-stroom, Toegangstoken in OpenID Connect is dit een waarde die niet duidelijk is CLIËNT'bij. Vanuit oogpunt CLIËNT'а Toegangstoken vertegenwoordigt een tekenreeks die bij elk verzoek wordt doorgegeven aan Bronserver'y, die bepaalt of het token geldig is. ID-token vertegenwoordigt iets heel anders.
ID-token is een JWT
ID-token is een speciaal opgemaakte tekenreeks die bekend staat als JSON Web Token of JWT (soms worden JWT-tokens uitgesproken als "jots"). Voor externe waarnemers lijkt JWT misschien onbegrijpelijk gebrabbel, maar CLIËNT kan verschillende informatie uit de JWT halen, zoals ID, gebruikersnaam, inlogtijd, vervaldatum ID-token'a, de aanwezigheid van pogingen om de JWT te verstoren. Gegevens binnen ID-token'a worden genoemd toepassingen [beweringen].
In het geval van OIDC is er ook een standaardmanier waarop CLIËNT kan om aanvullende informatie over de persoon vragen [identiteit] van autorisatie server'a, bijvoorbeeld een e-mailadres gebruiken Toegangstoken.
Meer informatie over OAuth en OIDC
Daarom hebben we kort bekeken hoe OAuth en OIDC werken. Klaar om dieper te graven? Hier zijn aanvullende bronnen om u te helpen meer te leren over OAuth 2.0 en OpenID Connect Connect:
Zoals altijd, voel je vrij om commentaar te geven. Om op de hoogte te blijven van ons laatste nieuws, kunt u zich abonneren op и Oké voor ontwikkelaars!
PS van vertaler
Lees ook op onze blog:
- «";
- «";
- «";
- «.
Bron: www.habr.com