Let wel. vertaal.: Hierdie wonderlike artikel deur Okta verduidelik hoe OAuth en OIDC (OpenID Connect) op 'n eenvoudige en duidelike manier werk. Hierdie kennis sal nuttig wees vir ontwikkelaars, stelseladministrateurs, en selfs "gereelde gebruikers" van gewilde webtoepassings, wat heel waarskynlik ook vertroulike data met ander dienste uitruil.
In die Steentydperk van die internet was dit maklik om inligting tussen dienste te deel. Jy het eenvoudig jou login en wagwoord van een diens na 'n ander gegee, sodat hy jou rekening ingeskryf het en enige inligting ontvang het wat hy nodig het.
"Gee my jou bankrekening." “Ons belowe dat alles reg sal wees met die wagwoord en geld. Dis eerlik, eerlik!" *hee hee*
Gruwel! Niemand moet ooit van 'n gebruiker vereis om 'n gebruikersnaam en wagwoord te deel nie, geloofsbriewe, met 'n ander diens. Daar is geen waarborg dat die organisasie agter hierdie diens die data veilig sal hou en nie meer persoonlike inligting sal insamel as wat nodig is nie. Dit klink dalk mal, maar sommige toepassings gebruik steeds hierdie praktyk!
Vandag is daar 'n enkele standaard wat een diens toelaat om die data van 'n ander veilig te gebruik. Ongelukkig gebruik sulke standaarde baie jargon en terme, wat hul begrip bemoeilik. Die doel van hierdie materiaal is om te verduidelik hoe hulle werk deur eenvoudige illustrasies te gebruik (Dink jy dat my tekeninge soos kinders se vlekke lyk? Ag tog!).
Terloops, hierdie gids is ook in videoformaat beskikbaar:
Dames en here, welkom: OAuth 2.0
is 'n sekuriteitstandaard wat een toepassing toelaat om toestemming te kry om toegang tot inligting in 'n ander toepassing te verkry. Volgorde van stappe vir die uitreiking van 'n permit [toestemming] (Of toestemming [toestemming]) dikwels bel magtiging [magtiging] of selfs gedelegeerde magtiging [gedelegeerde magtiging]. Met hierdie standaard laat jy 'n toepassing toe om data te lees of die funksies van 'n ander toepassing namens jou te gebruik sonder om dit jou wagwoord te gee. Klas!
As 'n voorbeeld, kom ons sê jy ontdek 'n webwerf genaamd "Ongelukkige woordspeling van die dag" [Verskriklike woordspeling van die dag] en besluit om daarop te registreer om daagliks woordspelings in die vorm van teksboodskappe op die foon te ontvang. Jy het baie van die webwerf gehou, en jy het besluit om dit met al jou vriende te deel. Almal hou immers van creepy woordspelings, nie waar nie?
“Ongelukkige woordspeling van die dag: Gehoor van die ou wat die linker helfte van sy lyf verloor het? Nou is hy altyd reg!” (geskatte vertaling, want die oorspronklike het sy eie woordspeling - ongeveer vertaal.)
Dit is duidelik dat skryf aan elke persoon uit die kontaklys nie 'n opsie is nie. En, as jy selfs 'n bietjie soos ek is, dan sal jy enige moeite doen om onnodige werk te vermy. Gelukkig kan Terrible Pun of the Day al jou vriende alleen nooi! Om dit te doen, hoef jy net toegang tot jou kontakte se e-pos oop te maak - die webwerf self sal vir hulle uitnodigings stuur (OAuth-reëls)!
“Almal is mal oor woordspelings! - Reeds aangemeld? “Wil jy die Terrible Pun of the Day-webwerf toelaat om toegang tot jou kontaklys te kry? - Dankie! Van nou af sal ons elke dag aanmanings stuur aan almal wat jy ken, tot die einde van die tyd! Jy is die beste vriend!"
- Kies jou e-posdiens.
- Indien nodig, gaan na die poswebwerf en meld aan by jou rekening.
- Gee Terrible Pun of the Day toestemming om toegang tot jou kontakte te kry.
- Keer terug na die Terrible Pun of the Day-werf.
As jy van plan verander, bied toepassings wat OAuth gebruik ook 'n manier om toegang te herroep. Sodra jy besluit dat jy nie meer kontakte met Terrible Pun of the Day wil deel nie, kan jy na die poswebwerf gaan en die woordspelingwerf van die lys van gemagtigde toepassings verwyder.
OAuth-vloei
Ons het pas deurgegaan wat gewoonlik genoem word vloei [vloei] OAuth. In ons voorbeeld bestaan hierdie vloei uit sigbare stappe, sowel as verskeie onsigbare stappe, waarin twee dienste ooreenkom oor 'n veilige uitruil van inligting. Die vorige Terrible Pun of the Day-voorbeeld gebruik die mees algemene OAuth 2.0-vloei, bekend as die "magtigingskode"-vloei. ["magtigingskode" vloei].
Voordat ons in die besonderhede van hoe OAuth werk, praat, kom ons praat oor die betekenis van sommige terme:
- Hulpbron eienaar:
Dit is jy! Jy besit jou geloofsbriewe, jou data en beheer alle aktiwiteite wat op jou rekeninge uitgevoer mag word. - Kliënt:
'n Toepassing (byvoorbeeld die Terrible Pun of the Day-diens) wat toegang tot sekere handelinge wil verkry of namens Hulpbron eienaar'à. - Magtigingsbediener:
Die app wat weet Hulpbron eienaar'a en waarin u Hulpbron eienaar'n het reeds 'n rekening. - hulpbronbediener:
Toepassingsprogrammeringskoppelvlak (API) of diens wat Kliënt namens wil gebruik Hulpbron eienaar'à. - Herlei URI:
Die skakel wat Magtigingsbediener sal herlei Hulpbron eienaar'en nadat toestemming verleen is Kliënt'by. Dit word soms na verwys as die "terugbel-URL". - tipe reaksie:
Die tipe inligting wat verwag word om ontvang te word Kliënt. Die mees algemene tipe reaksie'ohm is die kode, dit wil sê Kliënt verwag om te ontvang Magtigingskode. - Omvang:
Dit is 'n gedetailleerde beskrywing van die toestemmings wat vereis word Kliënt'y, soos toegang tot data of die uitvoering van sekere handelinge. - Toestemming:
Magtigingsbediener beret Scopesaangevra Kliënt'om, en vra Hulpbron eienaar'a, is hy gereed om te voorsien Kliënt'het die toepaslike toestemmings. - Kliënt-ID:
Hierdie ID word gebruik om te identifiseer Kliënt'a aan Magtigingsbediener'e. - Kliëntgeheim:
Dit is die wagwoord wat slegs bekend is Kliënt'jy en Magtigingsbediener'by. Dit stel hulle in staat om inligting privaat te deel. - Magtigingskode:
Tydelike kode met 'n kort tydperk van geldigheid, wat Kliënt bied Magtigingsbediener'y in ruil vir Toegangstoken. - Toegangstoken:
Die sleutel waarmee die kliënt sal gebruik om mee te kommunikeer hulpbronbediener'om. 'n Soort kenteken of sleutelkaart wat voorsien Kliënt'toestemming hê om data aan te vra of aksies uit te voer hulpbronbediener'e namens jou.
Let daarop: Soms is magtigingsbediener en hulpbronbediener dieselfde bediener. In sommige gevalle kan dit egter verskillende bedieners wees, selfs al behoort hulle nie aan dieselfde organisasie nie. Byvoorbeeld, die magtigingbediener kan 'n derdepartydiens wees wat deur die hulpbronbediener vertrou word.
Noudat ons die kernbegrippe van OAuth 2.0 gedek het, kom ons gaan terug na ons voorbeeld en kyk van nader na wat in die OAuth-vloei gebeur.
- Jy, Hulpbron eienaar, wil jy die Terrible Pun of the Day-diens lewer (Kliënty) toegang tot jou kontakte sodat hulle uitnodigings aan al jou vriende kan stuur.
- Kliënt herlei die blaaier na die bladsy Magtigingsbediener'a en sluit in navraag Kliënt-ID, Herlei URI, tipe reaksie en een of meer Scopes (toestemmings) wat dit nodig het.
- Magtigingsbediener verifieer jou, vra vir 'n gebruikersnaam en wagwoord indien nodig.
- Magtigingsbediener 'n vorm vertoon Toestemming (bevestigings) met 'n lys van almal Scopesaangevra Kliënt'om. Jy stem saam of weier.
- Magtigingsbediener herlei jou na die webwerf Kliënt'a, gebruik Herlei URI saam met Magtigingskode (Magtigingskode).
- Kliënt direk met kommunikeer Magtigingsbediener'ohm (omseil die blaaier Hulpbron eienaar'a) en veilig stuur Kliënt-ID, Kliëntgeheim и Magtigingskode.
- Magtigingsbediener kontroleer die data en reageer met Toegangstoken'om (toegangsteken).
- nou Kliënt kan gebruik Toegangstoken om 'n versoek te stuur hulpbronbediener om 'n lys van kontakte te kry.
Kliënt-ID en geheim
Lank voordat jy Terrible Pun of the Day toegelaat het om toegang tot jou kontakte te kry, het die kliënt en magtigingsbediener 'n werksverhouding gevestig. Die magtigingsbediener het die kliënt-ID en kliëntgeheim (soms genoem app ID и Toepassing geheim) en het dit aan die kliënt gestuur vir verdere interaksie binne OAuth.
"- Hallo! Ek wil graag saam met jou werk! - Natuurlik, nie 'n probleem nie! Hier is jou kliënt ID en geheim!”
Die naam dui daarop dat die kliëntgeheim geheim gehou moet word sodat slegs die kliënt en magtigingsbediener dit weet. Dit is immers met sy hulp dat die Magtigingsbediener die waarheid van die Kliënt bevestig.
Maar dit is nie al nie... Welkom asseblief OpenID Connect!
OAuth 2.0 is slegs ontwerp vir magtiging - om toegang tot data en funksies van een toepassing na 'n ander te verskaf. (OIDC) is 'n dun laag bo-op OAuth 2.0 wat die aanmeld- en profielbesonderhede byvoeg van die gebruiker wat by die rekening aangemeld is. Daar word dikwels na die organisasie van 'n aanmeldsessie verwys as verifikasie [stawing], en inligting oor die gebruiker wat by die stelsel aangemeld is (d.w.s. oor Hulpbron eienaar'e), — persoonlike data [identiteit]. As die magtigingsbediener OIDC ondersteun, word dit soms na verwys as verskaffer van persoonlike data [identiteitsverskaffer]want dit verskaf Kliënt' het inligting oor Hulpbron eienaar'e.
OpenID Connect laat jou toe om scenario's te implementeer waar 'n enkele aanmelding in verskeie toepassings gebruik kan word - hierdie benadering staan ook bekend as enkele aanmelding (SSO). Byvoorbeeld, 'n toepassing kan SSO-integrasie met sosiale netwerke soos Facebook of Twitter ondersteun, wat gebruikers toelaat om 'n rekening te gebruik wat hulle reeds het en verkies om te gebruik.
Die vloei (vloei) OpenID Connect lyk dieselfde as in die geval van OAuth. Die enigste verskil is dat in die primêre versoek, die spesifieke omvang wat gebruik word openid, - A Kliënt uiteindelik raak soos ToegangstokenEn ID-teken.
Net soos in die OAuth-vloei, Toegangstoken in OpenID Connect, is dit 'n waarde wat nie duidelik is nie Kliënt'by. Vanuit oogpunt Kliënt'A Toegangstoken verteenwoordig 'n string karakters wat saam met elke versoek aangegee word hulpbronbediener'y, wat bepaal of die teken geldig is. ID-teken verteenwoordig 'n heeltemal ander ding.
ID Token is 'n JWT
ID-teken is 'n spesiaal geformateerde string karakters bekend as JSON Web Token of JWT (soms word JWT-tekens soos "jots" uitgespreek). Vir waarnemers van buite lyk JWT dalk na onbegryplike brabbeltaal, maar Kliënt kan verskeie inligting uit die JWT onttrek, soos ID, gebruikersnaam, aanmeldtyd, vervaldatum ID-teken'a, die teenwoordigheid van pogings om met die JWT in te meng. Data binne ID-teken'a word genoem toepassings [eise].
In die geval van OIDC is daar ook 'n standaard manier waarop Kliënt kan addisionele inligting oor die individu aanvra [identiteit] van Magtigingsbediener'n, byvoorbeeld, 'n e-posadres wat Toegangstoken.
Kom meer te wete oor OAuth en OIDC
Dus, ons het kortliks nagegaan hoe OAuth en OIDC werk. Gereed om dieper te delf? Hier is bykomende hulpbronne om jou te help om meer te wete te kom oor OAuth 2.0 en OpenID Connect:
Soos altyd, voel vry om kommentaar te lewer. Om op hoogte te bly van ons jongste nuus, teken in op и Okta vir ontwikkelaars!
PS van vertaler
Lees ook op ons blog:
- «»;
- «»;
- «»;
- «".
Bron: will.com