Merk. overs.: Denne flotte artikkelen av Okta forklarer hvordan OAuth og OIDC (OpenID Connect) fungerer på en enkel og tydelig måte. Denne kunnskapen vil være nyttig for utviklere, systemadministratorer og til og med "vanlige brukere" av populære nettapplikasjoner, som mest sannsynlig også utveksler konfidensiell data med andre tjenester.
I Internetts steinalder var det enkelt å dele informasjon mellom tjenester. Du ga ganske enkelt innlogging og passord fra en tjeneste til en annen, slik at han kom inn på kontoen din og fikk all informasjon han trengte.
"Gi meg bankkontoen din." «Vi lover at alt skal gå bra med passord og penger. Det er ærlig, ærlig!" *ha ha*
Skrekk! Ingen skal noensinne kreve at en bruker deler brukernavn og passord, legitimasjon, med en annen tjeneste. Det er ingen garanti for at organisasjonen bak denne tjenesten vil holde dataene sikre og ikke samle inn mer personlig informasjon enn nødvendig. Det høres kanskje sprøtt ut, men noen apper bruker fortsatt denne praksisen!
I dag er det en enkelt standard som gjør at en tjeneste trygt kan bruke dataene til en annen. Dessverre bruker slike standarder mye sjargong og termer, noe som kompliserer deres forståelse. Hensikten med dette materialet er å forklare hvordan de fungerer ved hjelp av enkle illustrasjoner (Tror du at tegningene mine minner om barns daubing? Jaja!).
Denne veiledningen er forresten også tilgjengelig i videoformat:
Mine damer og herrer, velkommen: OAuth 2.0
er en sikkerhetsstandard som lar en applikasjon få tillatelse til å få tilgang til informasjon i en annen applikasjon. Rekkefølge av trinn for utstedelse av tillatelse [tillatelse] (eller samtykke [samtykke]) ringer ofte autorisasjon [autorisasjon] eller delegert fullmakt [delegert autorisasjon]. Med denne standarden lar du en applikasjon lese data eller bruke funksjonene til en annen applikasjon på dine vegne uten å oppgi passordet ditt. Klasse!
Som et eksempel, la oss si at du oppdager et nettsted som heter "Dagens uheldige ordspill" [Dagens forferdelige ordspill] og bestemte seg for å registrere seg på den for å motta daglige ordspill i form av tekstmeldinger på telefonen. Du likte siden veldig godt, og du bestemte deg for å dele den med alle vennene dine. Tross alt liker alle skumle ordspill, ikke sant?
«Dagens uheldige ordspill: Hørt om fyren som mistet venstre halvdel av kroppen? Nå har han alltid rett!» (omtrentlig oversettelse, fordi originalen har sitt eget ordspill - ca. oversettelse)
Det er klart at det ikke er et alternativ å skrive til hver person fra kontaktlisten. Og hvis du til og med er litt som meg, vil du strekke deg langt for å unngå unødvendig arbeid. Heldigvis kan Terrible Pun of the Day invitere alle vennene dine alene! For å gjøre dette trenger du bare å åpne tilgangen til kontaktenes e-post - nettstedet selv vil sende dem invitasjoner (OAuth-regler)!
«Alle elsker ordspill! - Allerede logget inn? "Vil du la nettstedet Terrible Pun of the Day få tilgang til kontaktlisten din? - Takk skal du ha! Fra nå av vil vi sende påminnelser hver dag til alle du kjenner, helt til tidenes ende! Du er den beste vennen!"
- Velg din e-posttjeneste.
- Om nødvendig, gå til e-postsiden og logg på kontoen din.
- Gi Dagens Terrible Pun tillatelse til å få tilgang til kontaktene dine.
- Gå tilbake til nettstedet Terrible Pun of the Day.
Hvis du ombestemmer deg, gir applikasjoner som bruker OAuth også en måte å tilbakekalle tilgang. Når du bestemmer deg for at du ikke lenger ønsker å dele kontakter med Dagens Terrible Pun, kan du gå til e-postsiden og fjerne ordspillsiden fra listen over autoriserte applikasjoner.
OAuth-flyt
Vi har nettopp gått gjennom det som vanligvis kalles strømme [strømme] OAuth. I vårt eksempel består denne flyten av synlige trinn, samt flere usynlige trinn, der to tjenester blir enige om en sikker utveksling av informasjon. Det forrige Dagens Terrible Pun-eksemplet bruker den vanligste OAuth 2.0-flyten, kjent som "autorisasjonskode"-flyten. ["autorisasjonskode" flyt].
Før vi dykker ned i detaljene om hvordan OAuth fungerer, la oss snakke om betydningen av noen begreper:
- Reseier:
Det er deg! Du eier legitimasjonen din, dataene dine og kontrollerer alle aktiviteter som kan utføres på kontoene dine. - kunde:
En applikasjon (for eksempel tjenesten Terrible Pun of the Day) som ønsker å få tilgang til eller utføre bestemte handlinger på vegne av Reseier'а. - Autorisasjonsserver:
Appen som vet Reseier'a og der u Reseier'a har allerede en konto. - Ressursserver:
Applikasjonsprogrammeringsgrensesnitt (API) eller tjeneste som kunde ønsker å bruke på vegne Reseier'а. - Omdiriger URI:
Linken som Autorisasjonsserver vil omdirigere Reseier'og etter å ha gitt tillatelse kunde'på. Det blir noen ganger referert til som "Callback URL". - Svartype:
Typen informasjon som forventes å bli mottatt kunde. Den vanligste Svartype'ohm er koden, altså kunde forventer å motta Godkjennelseskoden. - Omfang:
Dette er en detaljert beskrivelse av tillatelsene som kreves kunde'y, for eksempel tilgang til data eller utføre visse handlinger. - Samtykke:
Autorisasjonsserver beret ScopesForespurt kunde'om, og spør Reseier'a, er han klar til å gi kunde'ha de nødvendige tillatelsene. - kunde-ID:
Denne ID-en brukes til å identifisere kunde'a på Autorisasjonsserver'e. - Klienthemmelighet:
Dette er passordet som bare er kjent kunde'du og Autorisasjonsserver'på. Det lar dem dele informasjon privat. - Godkjennelseskoden:
Midlertidig kode med kort gyldighetstid, som kunde gir Autorisasjonsserver'y i bytte mot tilgang Token. - tilgang Token:
Nøkkelen som klienten vil bruke til å kommunisere med Ressursserver'om. Et slags merke eller nøkkelkort som gir kunde'ha tillatelse til å be om data eller utføre handlinger på Ressursserverpå dine vegne.
Note: Noen ganger er autorisasjonsserver og ressursserver samme server. Men i noen tilfeller kan dette være forskjellige servere, selv om de ikke tilhører samme organisasjon. Autorisasjonsserveren kan for eksempel være en tredjepartstjeneste som er klarert av ressursserveren.
Nå som vi har dekket kjernekonseptene til OAuth 2.0, la oss gå tilbake til eksemplet vårt og se nærmere på hva som skjer i OAuth-flyten.
- Du, Reseier, vil du tilby tjenesten Terrible Pun of the Day (kundey) tilgang til kontaktene dine slik at de kan sende invitasjoner til alle vennene dine.
- kunde omdirigerer nettleseren til siden Autorisasjonsserver'a og inkludere i spørringen kunde-ID, Omdiriger URI, Svartype og en eller flere Scopes (tillatelser) den trenger.
- Autorisasjonsserver verifiserer deg, ber om brukernavn og passord om nødvendig.
- Autorisasjonsserver viser et skjema Samtykke (bekreftelser) med en liste over alle ScopesForespurt kunde'om. Du samtykker eller nekter.
- Autorisasjonsserver omdirigerer deg til nettstedet kunde'a, bruker Omdiriger URI med Godkjennelseskoden (Godkjennelseskoden).
- kunde kommuniserer direkte med Autorisasjonsserver'ohm (omgå nettleseren Reseier'a) og sender trygt kunde-ID, Klienthemmelighet и Godkjennelseskoden.
- Autorisasjonsserver sjekker dataene og svarer med tilgang Token'om (tilgangstoken).
- Nå kunde kan bruke tilgang Token å sende en forespørsel til Ressursserver for å få en liste over kontakter.
Klient-ID og hemmelighet
Lenge før du lot Terrible Pun of the Day få tilgang til kontaktene dine, hadde klient- og autorisasjonsserveren etablert et arbeidsforhold. Autorisasjonsserveren genererte klient-IDen og klienthemmeligheten (noen ganger kalt App-ID и Apphemmelighet) og sendte dem til klienten for videre interaksjon innen OAuth.
"- Hallo! Jeg vil gjerne jobbe med deg! - Jada, ikke noe problem! Her er din klient-ID og hemmelighet!"
Navnet tilsier at klienthemmeligheten må holdes hemmelig slik at bare klienten og autorisasjonsserveren kjenner den. Tross alt er det med hans hjelp at autorisasjonsserveren bekrefter sannheten til klienten.
Men det er ikke alt... Velkommen til OpenID Connect!
OAuth 2.0 er kun designet for autorisasjon - å gi tilgang til data og funksjoner fra en applikasjon til en annen. (OIDC) er et tynt lag på toppen av OAuth 2.0 som legger til påloggings- og profildetaljene til brukeren som er logget på kontoen. Organiseringen av en påloggingsøkt blir ofte referert til som autentisering [autentisering], og informasjon om brukeren som er logget på systemet (dvs. ca Reseier'e), — personlig informasjon [identitet]. Hvis autorisasjonsserveren støtter OIDC, blir den noen ganger referert til som leverandør av personopplysninger [identitetsleverandør]fordi det gir kunde'ha informasjon om Reseier'e.
OpenID Connect lar deg implementere scenarier der en enkelt pålogging kan brukes i flere applikasjoner - denne tilnærmingen er også kjent som enkelt pålogging (SSO). For eksempel kan en applikasjon støtte SSO-integrasjon med sosiale nettverk som Facebook eller Twitter, slik at brukere kan bruke en konto de allerede har og foretrekker å bruke.
Flyten (flyten) OpenID Connect ser den samme ut som i tilfellet med OAuth. Den eneste forskjellen er at i den primære forespørselen er det spesifikke omfanget som brukes openid, - A kunde til slutt blir som tilgang TokenOg ID-token.
Akkurat som i OAuth-flyten, tilgang Token i OpenID Connect er dette en verdi som ikke er tydelig kunde'på. Fra synspunkt kunde'EN tilgang Token representerer en streng med tegn som sendes sammen med hver forespørsel til Ressursserver'y, som avgjør om tokenet er gyldig. ID-token representerer en helt annen ting.
ID-token er en JWT
ID-token er en spesialformatert streng med tegn kjent som JSON Web Token eller JWT (noen ganger uttales JWT-tokens som "jots"). For observatører utenfor kan JWT virke som uforståelig vrøvl, men kunde kan trekke ut ulike opplysninger fra JWT, som ID, brukernavn, påloggingstid, utløpsdato ID-token'a, tilstedeværelsen av forsøk på å forstyrre JWT. Data inne ID-token'a blir kalt applikasjoner [påstander].
Når det gjelder OIDC, er det også en standard måte kunde kan be om ytterligere informasjon om den enkelte [identitet] fra Autorisasjonsserver'en, for eksempel, en e-postadresse som bruker tilgang Token.
Finn ut mer om OAuth og OIDC
Så vi gjennomgikk kort hvordan OAuth og OIDC fungerer. Klar til å grave dypere? Her er flere ressurser for å hjelpe deg å lære mer om OAuth 2.0 og OpenID Connect:
Som alltid, kommenter gjerne. For å holde deg oppdatert med våre siste nyheter, abonner på и Okta for utviklere!
PS fra oversetter
Les også på bloggen vår:
- «";
- «";
- «";
- «'.
Kilde: www.habr.com