Opmerking vertaler.: In dit geweldige materiaal van Okta wordt eenvoudig en duidelijk de werking van OAuth en OIDC (OpenID Connect) uitgelegd. Deze kennis is nuttig voor ontwikkelaars, systeembeheerders en zelfs 'gemiddelde gebruikers' van populaire webapplicaties, die vermoedelijk ook gevoelige gegevens uitwisselen met andere diensten.
In het 'stenen tijdperk' van het internet was het eenvoudig om informatie tussen diensten te delen. Je gaf gewoon je inlognaam en wachtwoord van de ene dienst aan de andere, zodat deze in jouw account kon inloggen en de benodigde informatie kon verkrijgen.
"Geef je bankrekening op." — "We beloven dat alles met je wachtwoord en geld in orde komt. Echt, heel eerlijk!" *haha*
Jemig! Niemand mag ooit van een gebruiker eisen dat deze zijn inlognaam en wachtwoord, zijn gegevens, met een andere dienst deelt. Er is geen garantie dat de organisatie achter deze dienst de gegevens veilig opslaat en niet meer persoonlijke informatie verzamelt dan nodig is. Het mag misschien vreemd lijken, maar sommige applicaties gebruiken deze praktijk nog steeds!
Vandaag de dag bestaat er een uniforme norm die het mogelijk maakt dat de ene dienst veilig gebruikmaakt van de gegevens van een andere. Helaas gebruiken dergelijke normen veel jargon en termen, wat het begrip ervan bemoeilijkt. Het doel van dit materiaal is om met behulp van eenvoudige illustraties uit te leggen hoe ze werken (Denk je dat mijn tekeningen op kinderlijke krabbels lijken? Nou en?).
Overigens is deze handleiding ook beschikbaar in videoformaat:
Dames en heren, ontmoet: OAuth 2.0
— dit is een beveiligingsstandaard die het mogelijk maakt voor één applicatie om toestemming te krijgen om toegang te krijgen tot informatie in een andere applicatie. De stappen voor het geven van toestemming [permission] (of toestemming [consent]) worden vaak aangeduid als autorisatie [authorization] of zelfs gedelegeerde autorisatie [delegated authorization]. Met deze standaard sta je een applicatie toe om gegevens of functies van een andere applicatie namens jou te gebruiken, zonder je wachtwoord te delen. Geweldig!
Als voorbeeld stel je voor dat je een website tegenkomt met de naam "Vreselijk Pun van de Dag" [Terrible Pun of the Day] en besloten zich daarop te registreren om dagelijks woordgrappen in de vorm van sms-berichten op hun telefoon te ontvangen. De website beviel je erg, en je besloot het met al je bekenden te delen. Want verschrikkelijke woordgrappen vindt iedereen leuk, nietwaar?
«Mislukte woordgrap van de dag: Heb je gehoord van de jongen die de linkerkant van zijn lichaam kwijt is? Hij is nu altijd recht!» (vertaling is ongeveer, omdat de originele een eigen woordspeling bevat — red.)
Het is duidelijk dat het niet praktisch is om elke persoon in je contactlijst te benaderen. En als je ook maar een beetje op mij lijkt, kun je alles doen om extra werk te vermijden. Gelukkig kan Terrible Pun of the Day zelf al je vrienden uitnodigen! Je hoeft alleen maar toegang tot je e-mailcontacten te geven — de site stuurt zelf uitnodigingen (OAuth is geweldig)!
«Iedereen houdt van woordgrappen! — Heb je je al aangemeld? — Wil je toegang geven aan de website Terrible Pun of the Day tot je contactenlijst? — Dank je! Nu zullen we elke dag herinneringen sturen naar iedereen die je kent, tot in de eeuwigheid! Jij bent de beste vriend!»
- Kies je e-mailservice.
- Ga indien nodig naar de e-mailsite en log in op je account.
- Geef de website Terrible Pun of the Day toestemming om toegang te krijgen tot je contacten.
- Ga terug naar de website Terrible Pun of the Day.
Als je van gedachten verandert, bieden applicaties die OAuth gebruiken ook een manier om de toegang te annuleren. Als je besluit dat je je contacten niet langer wilt delen met Terrible Pun of the Day, kun je naar de e-mailsite gaan en de website met de woordgrappen uit de lijst met geautoriseerde applicaties verwijderen.
OAuth-stroom
We hebben zojuist door wat vaak een stroom [flow] OAuth. In ons voorbeeld bestaat deze stroom uit zichtbare stappen, evenals enkele onzichtbare stappen waarin de twee diensten overeenkomen over een veilige informatie-uitwisseling. In het vorige voorbeeld met Terrible Pun of the Day wordt de meest gangbare OAuth 2.0-stroom gebruikt, bekend als de 'autorisatiecode'-stroom. [«authorization code» flow].
Voordat we dieper ingaan op de werking van OAuth, laten we het hebben over de betekenis van enkele termen:
- Resource Owner:
Dat ben jij! Jij bezit je inloggegevens, je gegevens en beheert alle acties die met je accounts kunnen worden uitgevoerd. - Client:
Een toepassing (bijvoorbeeld de service Terrible Pun of the Day) die toegang wil krijgen of bepaalde handelingen namens Resource Ownerheeft. - Autorisatie Server:
Een toepassing die weet Resource Ownerheeft en waarin Resource Ownerde gebruiker al een account heeft. - Resource Server:
Een applicatie-programmeerinterface (API) of dienst die Client de gebruiker namens Resource Ownerheeft. - Redirect URI:
De link waarnaar Autorisatie Server de gebruiker zal worden doorgestuurd Resource Ownerna het verlenen van toestemming Clientaan . Soms wordt dit ook een 'Return URL' (ook wel 'Callback URL') genoemd. - Response Type:
Het type informatie dat Clientwordt verwacht. Het meest voorkomende Response Typeis een code, dat wil zeggen Client waarvoor men verwacht te ontvangen Autorisatie Code. - Scope:
Dit is een gedetailleerde beschrijving van de machtigingen die verzocht worden Clientdoor de gebruiker, zoals toegang tot gegevens of het uitvoeren van bepaalde handelingen. - Toestemming:
Autorisatie Server vraagt Scopesdie door de gebruiker worden aangevraagd, en vraagt aan Clientde gebruiker of deze bereid is Resource Ownerdeze machtigingen te verlenen. ClientDeze ID wordt gebruikt om - Cliënt ID:
de gebruiker te identificeren Clienttijdens de sessie. Autorisatie ServerClient Secret - Dit is een wachtwoord dat alleen bekend is bij:
de gebruiker en Clientde server. Het stelt hen in staat om op een vertrouwelijke manier informatie uit te wisselen. Autorisatie ServerEen tijdelijke code met een korte geldigheidsduur die - Autorisatie Code:
de gebruiker in ruil voor Client biedt Autorisatie ServerAccess Token Een sleutel die de client zal gebruiken om te communiceren met. - Een sleutel die de client zal gebruiken om te communiceren met:
de server. Dit is als een badge of sleutelkaart die Resource Serverde gebruiker toestemming geeft om gegevens op te vragen of handelingen uit te voeren namens Clientde server. Soms zijn de Autorisatie Server en Resource Server dezelfde server. In sommige gevallen kunnen dit echter verschillende servers zijn, die misschien niet eens tot dezelfde organisatie behoren. Bijvoorbeeld, de Autorisatie Server kan een externe service zijn die wordt vertrouwd door de Resource Server. Resource ServerNu we bekend zijn met de basisconcepten van OAuth 2.0, laten we teruggaan naar ons voorbeeld en in detail bekijken wat er gebeurt in de OAuth-stroom.
OpmerkingU wilt de service Terrible Pun of the Day (
toegang geven tot uw contacten, zodat deze uitnodigingen kan toezenden aan al uw vrienden.
- daarop de browser doorverwijst naar de pagina van Resource Owneren de aanvraag omvatClienten één of meerdere
- Client (machtigingen) die nodig zijn. Autorisatie Serverde gebruiker verifieert en, indien nodig, om inloggegevens vraagt. Cliënt ID, Redirect URI, Response Type een bevestigingsformulier weergeeft met een lijst van alle Scopes aanvragen die door
- Autorisatie Server zijn ingediend. U stemt toe of weigert.
- Autorisatie Server de gebruiker wordt doorgestuurd naar de website van Toestemming met behulp van Scopes(de autorisatiecode). Clientdirect in contact komt met
- Autorisatie Server de server (omzeilt de browser van Clientde gebruiker) en veilig verzendt. Redirect URI samen met Autorisatie Code de gegevens.
- Client de gebruiker Autorisatie Serverde server. Resource Ownerde gegevens Cliënt ID, Dit is een wachtwoord dat alleen bekend is bij en Autorisatie Code.
- Autorisatie Server controleert de gegevens en reageert met Een sleutel die de client zal gebruiken om te communiceren met‘ (toegangstoken).
- Nu Client kan gebruiken Een sleutel die de client zal gebruiken om te communiceren met om een aanvraag te verzenden naar Resource Server om een lijst van contacten te verkrijgen.
Client ID en Secret
Lang voordat u Terrible Pun of the Day toestemming gaf om toegang te krijgen tot de contacten, hebben Client en Authorization Server een werkrelatie opgebouwd. Authorization Server genereerde de Client ID en Client Secret (soms ook wel genoemd App ID en App Secret) en stuurde deze naar de Client voor verdere interactie binnen OAuth.
‘— Hallo! Ik wil graag met je samenwerken! — Geen probleem! Hier zijn je Client ID en Secret!’
De naam suggereert dat de Client Secret geheim moet worden gehouden, zodat alleen de Client en Authorization Server ervan op de hoogte zijn. Het is immers met behulp hiervan dat de Authorization Server de authenticiteit van de Client bevestigt.
Maar dat is nog niet alles... Laat OpenID Connect een warm welkom geven!
OAuth 2.0 is specifiek ontworpen voor autorisatie — het verlenen van toegang tot gegevens en functies van de ene applicatie aan de andere. (OIDC) is een dunne laag bovenop OAuth 2.0, die login- en profielinformatie toevoegt van de gebruiker die is aangemeld. De organisatie van de login-sessie wordt vaak aangeduid als authenticatie [authentication], en de informatie over de ingelogde gebruiker (d.w.z. over Resource Owner‘) — persoonsgegevens [identity]. Als de Authorization Server OIDC ondersteunt, wordt deze soms aangeduid als gegevensleverancier [identity provider], omdat deze Client‘ informatie over Resource OwnerClient Secret
OpenID Connect maakt scenario's mogelijk waarbij een enkele aanmelding in meerdere applicaties kan worden gebruikt — deze aanpak staat ook bekend als single sign-on (SSO). Bijvoorbeeld, een applicatie kan SSO-integratie ondersteunen met sociale netwerken zoals Facebook of Twitter, waardoor gebruikers een account kunnen gebruiken dat ze al hebben en dat ze prefereren.
De OpenID Connect-flow ziet er hetzelfde uit als die van OAuth. Het enige verschil is dat in de initiële aanvraag de specifieke scope die gebruikt wordt — openid, — en Client uiteindelijk ontvangt als Een sleutel die de client zal gebruiken om te communiceren met, als voor ID Token.
Net als in de OAuth-flow, Een sleutel die de client zal gebruiken om te communiceren met in OpenID Connect — is dit een waarde die niet begrijpelijk is voor Client‘. Vanuit het perspectief van Client‘ vertegenwoordigt het een reeks karakters die met elke aanvraag naar Een sleutel die de client zal gebruiken om te communiceren met ‘ wordt verzonden, en deze bepaalt of het token geldig is. Resource Serveris iets heel anders. ID Token ID Token is een JWT
— dit is een op een speciale manier opgemaakte reeks karakters, bekend als JSON Web Token of JWT
ID Token (soms worden JWT-tokens uitgesproken als “jots”) (soms worden JWT-tokens uitgesproken als «jots»). Voor externe waarnemers kan JWT lijken op onbegrijpelijke abracadabra, maar Client kan verschillende informatie uit JWT extraheren, zoals ID, gebruikersnaam, inlogtijd en vervaldatum ID Tokenen pogingen tot interferentie met JWT. De gegevens binnen ID Tokenworden genoemd claims [claims].
In het geval van OIDC is er ook een standaard manier waarop Client extra informatie over de identiteit kan worden opgevraagd [identity] van Autorisatie Serverbijvoorbeeld een e-mailadres, met gebruik van Een sleutel die de client zal gebruiken om te communiceren met.
Extra informatie over OAuth en OIDC
Dus hebben we kort de principes van OAuth en OIDC besproken. Klaar om dieper in te gaan? Hier zijn extra bronnen die helpen meer te leren over OAuth 2.0 en OpenID Connect:
Voel je vrij om opmerkingen achter te laten, zoals gebruikelijk. Blijf op de hoogte van onze nieuwste updates door je in te schrijven voor en Okta voor ontwikkelaars!
P.S. van de vertaler
Lees ook op onze blog:
- «»;
- «»;
- «»;
- «».
Bron: habr.com
