Notu. transl.: Ĉi tiu bonega artikolo de Okta klarigas kiel OAuth kaj OIDC (OpenID Connect) funkcias en simpla kaj klara maniero. Ĉi tiu scio estos utila al programistoj, sistemadministrantoj, kaj eĉ "regulaj uzantoj" de popularaj TTT-aplikoj, kiuj plej verŝajne ankaŭ interŝanĝas konfidencajn datumojn kun aliaj servoj.
En la Ŝtonepoko de Interreto, kunhavigi informojn inter servoj estis facila. Vi simple donis vian ensaluton kaj pasvorton de unu servo al alia, tiel ke li eniris vian konton kaj ricevis ajnajn informojn, kiujn li bezonis.
"Donu al mi vian bankkonton." “Ni promesas, ke ĉio estos bone kun la pasvorto kaj mono. Tio estas honesta, honesta!" *he he*
Teruro! Neniu iam devus postuli uzanton kunhavigi uzantnomon kaj pasvorton, akreditaĵojn, kun alia servo. Ne estas garantio, ke la organizo malantaŭ ĉi tiu servo konservos la datumojn sekuraj kaj ne kolektos pli da personaj informoj ol necese. Ĝi povas soni freneza, sed iuj programoj ankoraŭ uzas ĉi tiun praktikon!
Hodiaŭ ekzistas ununura normo, kiu permesas al unu servo sekure uzi la datumojn de alia. Bedaŭrinde tiaj normoj uzas multe da ĵargono kaj terminoj, kio malfaciligas ilian komprenon. La celo de ĉi tiu materialo estas klarigi kiel ili funkcias per simplaj ilustraĵoj (Ĉu vi pensas, ke miaj desegnaĵoj similas infanajn ŝmiraĵojn? Ho nu!).
Cetere, ĉi tiu gvidilo ankaŭ haveblas en videoformato:
Gesinjoroj, bonvenon: OAuth 2.0
estas sekurecnormo kiu permesas al unu aplikaĵo akiri permeson aliri informojn en alia aplikaĵo. Sekvo de paŝoj por eldonado de permesilo [permeso] (aŭ konsenti [konsento]) ofte vokas rajtigo [rajtigo] aŭ eĉ delegita rajtigo [delegita rajtigo]. Kun ĉi tiu normo, vi permesas al aplikaĵo legi datumojn aŭ uzi la funkciojn de alia aplikaĵo en via nomo sen doni al ĝi vian pasvorton. Klaso!
Ekzemple, ni diru, ke vi malkovras retejon nomitan "Malbonŝanca vortludo de la Tago" [Terura vortludo de la Tago] kaj decidis registriĝi sur ĝi por ricevi ĉiutagajn vortludojn en formo de tekstmesaĝoj ĉe la telefono. Vi tre ŝatis la retejon, kaj vi decidis dividi ĝin kun ĉiuj viaj amikoj. Post ĉio, ĉiuj ŝatas timigajn vortludojn, ĉu ne?
"Malfeliĉa vortludo de la tago: Aŭdis pri la ulo, kiu perdis la maldekstran duonon de sia korpo? Nun li ĉiam pravas!” (proksimuma traduko, ĉar la originalo havas propran vortludon - ĉ. traduk.)
Estas klare, ke skribi al ĉiu persono el la kontaktlisto ne estas eblo. Kaj, se vi estas eĉ iomete kiel mi, tiam vi klopodos por eviti nenecesan laboron. Feliĉe, Terura vortludo de la Tago povas inviti ĉiujn viajn amikojn per si mem! Por fari tion, vi nur bezonas malfermi aliron al retpoŝto de viaj kontaktoj - la retejo mem sendos al ili invitojn (reguloj de OAuth)!
“Ĉiuj amas vortludojn! - Ĉu vi jam ensalutis? “Ĉu vi ŝatus permesi al la retejo de Terura vortludo de la Tago aliri vian kontaktliston? - Dankon! De nun ni sendos memorigilojn ĉiutage al ĉiuj, kiujn vi konas, ĝis la fino de la tempo! Vi estas la plej bona amiko!"
- Elektu vian retpoŝtan servon.
- Se necese, iru al la retpoŝta retejo kaj ensalutu al via konto.
- Donu Teruran vortludon de la Tago permeson aliri viajn kontaktojn.
- Revenu al la retejo de Terura vortludo de la Tago.
Se vi ŝanĝas opinion, aplikaĵoj uzantaj OAuth ankaŭ provizas manieron revoki aliron. Post kiam vi decidas, ke vi ne plu volas kunhavigi kontaktojn kun Terura Pun of the Day, vi povas iri al la retpoŝta retejo kaj forigi la vortludon el la listo de rajtigitaj aplikoj.
OAuth Fluo
Ni ĵus trapasis tion, kion oni kutime nomas flui [fluo] OAuth. En nia ekzemplo, ĉi tiu fluo konsistas el videblaj paŝoj, same kiel pluraj nevideblaj paŝoj, en kiuj du servoj konsentas pri sekura interŝanĝo de informoj. La antaŭa Terrible Pun of the Day ekzemplo uzas la plej oftan OAuth 2.0-fluon, konatan kiel la "rajtiga kodo" fluo. [fluo de "rajtigokodo"].
Antaŭ ol plonĝi en la detalojn pri kiel funkcias OAuth, ni parolu pri la signifo de iuj terminoj:
- Rimedo-posedanto:
Estas vi! Vi posedas viajn akreditaĵojn, viajn datumojn, kaj kontrolas ĉiujn agadojn, kiuj povas esti faritaj sur viaj kontoj. - Kliento:
Apliko (ekzemple la Terura vortludo de la Taga servo) kiu volas aliri aŭ plenumi certajn agojn nome de Rimedo-posedanto'а. - Servilo de Rajto:
La app kiu scias Rimedo-posedanto'a kaj en kiu u Rimedo-posedanto'a jam havas konton. - rimeda servilo:
Apliko programado interfaco (API) aŭ servo kiu Kliento volas uzi nome Rimedo-posedanto'а. - Redirekta URI:
La ligo tio Servilo de Rajto alidirektos Rimedo-posedanto— kaj doninte permeson Kliento'je. Ĝi foje estas referita kiel la "Callback URL". - tipo de respondo:
La tipo de informoj atenditaj ricevi Kliento. La plej ordinara tipo de respondo— ohm estas la kodo, tio estas Kliento atendas ricevi Rajtiga Kodo. - amplekso:
Ĉi tio estas detala priskribo de la permesoj necesaj Kliento'y, kiel ekzemple aliri datumojn aŭ plenumi iujn agojn. - konsento:
Servilo de Rajto prenas Mediojpetis Kliento'om, kaj demandas Rimedo-posedanto— a, ĉu li pretas provizi Kliento'havu la taŭgajn permesojn. - Klienta ID:
Ĉi tiu identigilo estas uzata por identigi Kliento'a on Servilo de Rajto'e. - Klienta Sekreto:
Ĉi tiu estas la pasvorto, kiu estas nur konata Kliento'u kaj Servilo de Rajto'je. Ĝi permesas ilin kunhavigi informojn private. - Rajtiga Kodo:
Provizora kodo kun mallonga periodo de valideco, kiu Kliento provizas Servilo de Rajto'y interŝanĝe de Alira tokeno. - Alira tokeno:
La ŝlosilo, kun kiu la kliento uzos por komuniki rimeda servilo'om. Speco de insigno aŭ ŝlosilkarto kiu provizas Kliento'havas permeson peti datumojn aŭ fari agojn rimeda servilo'e en via nomo.
Примечание: Kelkfoje Rajtigo-Servilo kaj Rimeda Servilo estas la sama servilo. Tamen, en iuj kazoj, ĉi tiuj povas esti malsamaj serviloj, eĉ se ili ne apartenas al la sama organizo. Ekzemple, la Rajtigo-Servilo eble estas triaparta servo fidinda de la Rimeda Servilo.
Nun kiam ni kovris la kernkonceptojn de OAuth 2.0, ni reiru al nia ekzemplo kaj rigardu pli detale kio okazas en la OAuth-fluo.
- Vi, Rimedo-posedanto, vi volas provizi la Servon Terura vortludo de la Tago (Klientoy) aliro al viaj kontaktoj por ke ili povu sendi invitojn al ĉiuj viaj amikoj.
- Kliento redirektas la retumilon al la paĝo Servilo de Rajto'a kaj inkluzivi en demandon Klienta ID, Redirekta URI, tipo de respondo kaj unu aŭ pli Medioj (permesoj) ĝi bezonas.
- Servilo de Rajto kontrolas vin, petante uzantnomon kaj pasvorton se necese.
- Servilo de Rajto montras formon konsento (konfirmoj) kun listo de ĉiuj Mediojpetis Kliento'om. Vi konsentas aŭ rifuzas.
- Servilo de Rajto redirektas vin al la retejo Kliento'a, uzante Redirekta URI kune kun Rajtiga Kodo (rajtigokodo).
- Kliento komunikas rekte kun Servilo de Rajto'ohm (preterpasante la retumilon Rimedo-posedanto'a) kaj sekure sendas Klienta ID, Klienta Sekreto и Rajtiga Kodo.
- Servilo de Rajto kontrolas la datumojn kaj respondas per Alira tokeno'om (alirĵetono).
- Nun Kliento povas uzi Alira tokeno por sendi peton al rimeda servilo por ricevi liston de kontaktoj.
Kliento ID kaj Sekreto
Longe antaŭ ol vi permesis al Terura vortludo de la Tago aliri viajn kontaktojn, la Kliento kaj Rajtiga Servilo establis laborrilaton. La Rajtigo-Servilo generis la Klientidentigilon kaj Kliento-Sekreton (foje nomatan App-ID и Sekreta App) kaj sendis ilin al la Kliento por plia interago ene de OAuth.
"- Saluton! Mi ŝatus labori kun vi! - Certe, ne estas problemo! Jen via Kliento-ID kaj Sekreto!"
La nomo implicas, ke la Kliento-Sekreto devas esti sekreta por ke nur la Kliento kaj Rajtigo-Servilo sciu ĝin. Post ĉio, estas kun lia helpo ke la Rajtigo-Servilo konfirmas la veron de la Kliento.
Sed tio ne estas ĉio... Bonvolu bonvenigi OpenID Connect!
OAuth 2.0 estas desegnita nur por rajtigo - provizi aliron al datumoj kaj funkcioj de unu aplikaĵo al alia. (OIDC) estas maldika tavolo supre de OAuth 2.0 kiu aldonas la ensalutajn kaj profilajn detalojn de la uzanto kiu estas ensalutinta en la konton. La organizo de ensaluta sesio ofte estas referita kiel aŭtentikigo [aŭtentikigo], kaj informoj pri la uzanto ensalutinta en la sistemon (t.e. pri Rimedo-posedanto'e), — personaj datumoj [identeco]. Se la Rajtigo-Servilo subtenas OIDC, ĝi foje estas referita kiel provizanto de personaj datumoj [provizanto de identeco]ĉar ĝi provizas Kliento'havas informojn pri Rimedo-posedanto'e.
OpenID Connect ebligas al vi efektivigi scenarojn, kie ununura ensaluto povas esti uzata en pluraj aplikoj - ĉi tiu aliro ankaŭ estas konata kiel ununura ensaluto (SSO). Ekzemple, aplikaĵo povas subteni SSO-integriĝon kun sociaj retoj kiel Facebook aŭ Twitter, permesante al uzantoj uzi konton, kiun ili jam havas kaj preferas uzi.
La fluo (fluo) OpenID Connect aspektas same kiel en la kazo de OAuth. La nura diferenco estas, ke en la primara peto, la specifa amplekso uzata estas openid, - A Kliento eventuale akiras kiel Alira tokeno, kaj ID-ĵetono.
Same kiel en la OAuth-fluo, Alira tokeno en OpenID Connect, ĉi tio estas iu valoro, kiu ne estas klara Kliento'je. El vidpunkto Kliento'а Alira tokeno reprezentas ĉenon de signoj, kiuj estas transdonitaj kune kun ĉiu peto al rimeda servilo'y, kiu determinas ĉu la ĵetono estas valida. ID-ĵetono reprezentas tute alian aferon.
ID Token estas JWT
ID-ĵetono estas speciale formatita ĉeno de signoj konataj kiel JSON Web Token aŭ JWT (foje JWT-ĵetonoj estas prononcitaj kiel "jotoj"). Al eksteraj observantoj, JWT povas ŝajni kiel nekomprenebla babelo, sed Kliento povas ĉerpi diversajn informojn el la JWT, kiel ekzemple ID, uzantnomo, ensaluttempo, limdato ID-ĵetono'a, la ĉeesto de provoj malhelpi la JWT. Datumoj interne ID-ĵetono'a estas nomitaj aplikoj [asertoj].
En la kazo de OIDC, ekzistas ankaŭ norma maniero per kiu Kliento povas peti pliajn informojn pri la individuo [identeco] el Servilo de Rajto'a, ekzemple, retadreson uzanta Alira tokeno.
Lernu pli pri OAuth kaj OIDC
Do, ni mallonge reviziis kiel funkcias OAuth kaj OIDC. Ĉu vi pretas fosi pli profunde? Jen pliaj rimedoj por helpi vin lerni pli pri OAuth 2.0 kaj OpenID Connect:
Kiel ĉiam, bonvolu komenti. Por esti ĝisdatigita kun niaj plej novaj novaĵoj, abonu и Okta por programistoj!
PS de tradukisto
Legu ankaŭ en nia blogo:
- «»;
- «»;
- «»;
- «".
fonto: www.habr.com