Bemærk. overs.: Denne fantastiske artikel af Okta forklarer, hvordan OAuth og OIDC (OpenID Connect) fungerer på en enkel og overskuelig måde. Denne viden vil være nyttig for udviklere, systemadministratorer og endda "almindelige brugere" af populære webapplikationer, som højst sandsynligt også udveksler fortrolige data med andre tjenester.
I internettets stenalder var det nemt at dele information mellem tjenester. Du gav blot dit login og din adgangskode fra en tjeneste til en anden, så han kom ind på din konto og modtog de oplysninger, han havde brug for.
"Giv mig din bankkonto." ”Vi lover, at alt bliver godt med adgangskoden og pengene. Det er ærligt, ærligt!" *hee hee*
Rædsel! Ingen bør nogensinde kræve, at en bruger deler et brugernavn og en adgangskode, legitimationsoplysninger, med en anden tjeneste. Der er ingen garanti for, at organisationen bag denne service holder dataene sikre og ikke vil indsamle flere personlige oplysninger end nødvendigt. Det lyder måske skørt, men nogle apps bruger stadig denne praksis!
I dag er der en enkelt standard, der gør det muligt for en tjeneste at bruge en andens data sikkert. Desværre bruger sådanne standarder en masse jargon og termer, hvilket komplicerer deres forståelse. Formålet med dette materiale er at forklare, hvordan de fungerer ved hjælp af simple illustrationer (Tror du, at mine tegninger minder om børns daubing? Nå ja!).
Denne guide er i øvrigt også tilgængelig i videoformat:
Mine damer og herrer, velkommen: OAuth 2.0
er en sikkerhedsstandard, der tillader en applikation at få tilladelse til at få adgang til oplysninger i en anden applikation. Rækkefølge af trin for udstedelse af en tilladelse [tilladelse] (eller samtykke [samtykke]) ringer ofte bemyndigelse [bemyndigelse] eller uddelegeret bemyndigelse [delegeret autorisation]. Med denne standard tillader du en applikation at læse data eller bruge funktionerne i en anden applikation på dine vegne uden at give den din adgangskode. Klasse!
Lad os som et eksempel sige, at du opdager et websted kaldet "Dagens uheldige ordspil" [Dagens frygtelige ordspil] og besluttede at registrere sig på det for at modtage daglige ordspil i form af tekstbeskeder på telefonen. Du kunne virkelig godt lide siden, og du besluttede at dele den med alle dine venner. Alle kan jo godt lide uhyggelige ordspil, ikke?
“Dagens uheldige ordspil: Hørt om den fyr, der mistede venstre halvdel af sin krop? Nu har han altid ret!” (ca. oversættelse, fordi originalen har sit eget ordspil - ca. oversættelse)
Det er klart, at det ikke er en mulighed at skrive til hver person fra kontaktlisten. Og hvis du er lidt ligesom mig, så vil du gå alt for at undgå unødvendigt arbejde. Heldigvis kan Dagens frygtelige ordspil invitere alle dine venner af sig selv! For at gøre dette skal du blot åbne adgangen til dine kontakters e-mail - webstedet selv sender dem invitationer (OAuth-regler)!
“Alle elsker ordspil! - Allerede logget ind? "Vil du give webstedet Terrible Pun of the Day adgang til din kontaktliste? - Tak skal du have! Fra nu af sender vi påmindelser hver dag til alle, du kender, indtil tidens ende! Du er den bedste ven!"
- Vælg din e-mail-tjeneste.
- Gå om nødvendigt til mail-webstedet og log ind på din konto.
- Giv Dagens Terrible Pun tilladelse til at få adgang til dine kontakter.
- Vend tilbage til webstedet Terrible Pun of the Day.
Hvis du ombestemmer dig, giver applikationer, der bruger OAuth, også en måde at tilbagekalde adgang på. Når du beslutter dig for, at du ikke længere ønsker at dele kontakter med Dagens Terrible Pun, kan du gå til mail-webstedet og fjerne ordspil-webstedet fra listen over godkendte applikationer.
OAuth-flow
Vi har lige været igennem det, man plejer at kalde flyde [flyde] OAuth. I vores eksempel består dette flow af synlige trin, samt flere usynlige trin, hvor to tjenester aftaler en sikker udveksling af information. Det tidligere Terrible Pun of the Day-eksempel bruger det mest almindelige OAuth 2.0-flow, kendt som "autorisationskode"-flowet. ["autorisationskode" flow].
Før vi dykker ned i detaljerne om, hvordan OAuth fungerer, lad os tale om betydningen af nogle udtryk:
- Ressourceejer:
Det er dig! Du ejer dine legitimationsoplysninger, dine data og kontrollerer alle aktiviteter, der kan udføres på dine konti. - Klient:
En applikation (for eksempel tjenesten Terrible Pun of the Day), der ønsker at få adgang til eller udføre bestemte handlinger på vegne af Ressourceejer'а. - Autorisationsserver:
Appen der ved Ressourceejer'a og hvori u Ressourceejer'a har allerede en konto. - ressourceserver:
Application Programming Interface (API) eller service, der Klient ønsker at bruge på vegne Ressourceejer'а. - Omdiriger URI:
Linket der Autorisationsserver vil omdirigere Ressourceejer'og efter at have givet tilladelse Klient'på. Det omtales nogle gange som "Callback URL". - Svartype:
Den type information, der forventes at blive modtaget Klient. Den mest almindelige Svartype'ohm er koden, altså Klient forventer at modtage Autorisation kode. - Anvendelsesområde:
Dette er en detaljeret beskrivelse af de nødvendige tilladelser Klient'y, såsom at få adgang til data eller udføre bestemte handlinger. - Samtykke:
Autorisationsserver baret Scopesanmodet om Klient'om, og spørger Ressourceejer'a, er han klar til at yde Klient'har de relevante tilladelser. - kunde-id:
Dette ID bruges til at identificere Klient'a på Autorisationsserver'e. - Klienthemmelighed:
Dette er adgangskoden, der kun er kendt Klient'du og Autorisationsserver'på. Det giver dem mulighed for at dele information privat. - Autorisation kode:
Midlertidig kode med kort gyldighedsperiode, som Klient giver Autorisationsserver'y i bytte for Adgang Token. - Adgang Token:
Nøglen som klienten vil bruge til at kommunikere med ressourceserver'om. En slags badge eller nøglekort, der giver Klient'har tilladelse til at anmode om data eller udføre handlinger på ressourceserver'e på dine vegne.
Bemærk: Nogle gange er autorisationsserver og ressourceserver den samme server. I nogle tilfælde kan det dog være forskellige servere, selvom de ikke tilhører den samme organisation. For eksempel kan autorisationsserveren være en tredjepartstjeneste, som ressourceserveren har tillid til.
Nu hvor vi har dækket kernekoncepterne i OAuth 2.0, lad os gå tilbage til vores eksempel og se nærmere på, hvad der sker i OAuth-flowet.
- Du, Ressourceejer, du ønsker at levere tjenesten Terrible Pun of the Day (Klienty) adgang til dine kontakter, så de kan sende invitationer til alle dine venner.
- Klient omdirigerer browseren til siden Autorisationsserver'a og inkludere i forespørgslen kunde-id, Omdiriger URI, Svartype og en eller flere Scopes (tilladelser), den har brug for.
- Autorisationsserver bekræfter dig og beder om et brugernavn og en adgangskode, hvis det er nødvendigt.
- Autorisationsserver viser en formular Samtykke (bekræftelser) med en liste over alle Scopesanmodet om Klient'om. Du accepterer eller nægter.
- Autorisationsserver omdirigerer dig til webstedet Klient'a, ved hjælp af Omdiriger URI med Autorisation kode (autorisationskode).
- Klient kommunikerer direkte med Autorisationsserver'ohm (omgå browseren Ressourceejer'a) og sender sikkert kunde-id, Klienthemmelighed и Autorisation kode.
- Autorisationsserver tjekker dataene og svarer med Adgang Token'om (adgangstoken).
- Nu Klient kan bruge Adgang Token at sende en anmodning til ressourceserver for at få en liste over kontakter.
Klient-id og hemmelighed
Længe før du gav Dagens Terrible Pun adgang til dine kontakter, havde klienten og autorisationsserveren etableret et arbejdsforhold. Autorisationsserveren genererede klient-id'et og klienthemmeligheden (nogle gange kaldet App ID и Appens hemmelighed) og sendte dem til klienten for yderligere interaktion inden for OAuth.
"- Hej! Jeg vil gerne arbejde sammen med dig! - Selvfølgelig, ikke et problem! Her er dit klient-id og din hemmelighed!"
Navnet antyder, at klienthemmeligheden skal holdes hemmelig, så kun klienten og autorisationsserveren kender den. Det er trods alt med hans hjælp, at autorisationsserveren bekræfter klientens sandhed.
Men det er ikke alt... Velkommen til OpenID Connect!
OAuth 2.0 er kun designet til bemyndigelse - at give adgang til data og funktioner fra en applikation til en anden. (OIDC) er et tyndt lag oven på OAuth 2.0, der tilføjer login- og profildetaljerne for den bruger, der er logget ind på kontoen. Organiseringen af en login-session omtales ofte som Godkendelse [Godkendelse], og oplysninger om den bruger, der er logget ind på systemet (dvs. ca Ressourceejer'e), — personlig data [identitet]. Hvis autorisationsserveren understøtter OIDC, kaldes den nogle gange udbyder af personoplysninger [identitetsudbyder]fordi det giver Klient'har oplysninger om Ressourceejer'e.
OpenID Connect giver dig mulighed for at implementere scenarier, hvor et enkelt login kan bruges i flere applikationer - denne tilgang er også kendt som enkelt tilmelding (SSO). For eksempel kan en applikation understøtte SSO-integration med sociale netværk som Facebook eller Twitter, hvilket giver brugerne mulighed for at bruge en konto, de allerede har og foretrækker at bruge.
Flowet (flowet) OpenID Connect ser det samme ud som i tilfældet med OAuth. Den eneste forskel er, at i den primære anmodning er det anvendte specifikke omfang openid, - A Klient til sidst bliver ligesom Adgang TokenOg ID-token.
Ligesom i OAuth-flowet, Adgang Token i OpenID Connect er dette en værdi, der ikke er klar Klient'på. Fra synspunkt Klient'а Adgang Token repræsenterer en streng af tegn, der sendes sammen med hver anmodning til ressourceserver'y, som afgør, om tokenet er gyldigt. ID-token repræsenterer en helt anden ting.
ID-token er en JWT
ID-token er en specielt formateret streng af tegn kendt som JSON Web Token eller JWT (nogle gange udtales JWT-tokens som "jots"). For udefrakommende iagttagere kan JWT virke som uforståeligt volapyk, men Klient kan udtrække forskellige oplysninger fra JWT, såsom ID, brugernavn, login tid, udløbsdato ID-token'a, tilstedeværelsen af forsøg på at gribe ind i JWT. Data inde ID-token'a kaldes applikationer [påstande].
I tilfælde af OIDC er der også en standard måde, hvorpå Klient kan anmode om yderligere oplysninger om den enkelte [identitet] fra Autorisationsserver'en, for eksempel en e-mailadresse, der bruger Adgang Token.
Få mere at vide om OAuth og OIDC
Så vi gennemgik kort, hvordan OAuth og OIDC fungerer. Klar til at grave dybere? Her er yderligere ressourcer til at hjælpe dig med at lære mere om OAuth 2.0 og OpenID Connect:
Som altid er du velkommen til at kommentere. For at holde dig ajour med vores seneste nyheder, abonner på и Okta for udviklere!
PS fra oversætteren
Læs også på vores blog:
- «";
- «";
- «";
- «'.
Kilde: www.habr.com