Svarīgas lietas, kas jums jāzina par OAuth

OAuth ir kaut kas, kas jāzina katram izstrādātājam. Ja veidojat atsevišķu lietojumprogrammu vai trešās puses lietojumprogrammu, kas integrējas ar kādu citu HTTP pakalpojumu, jums jāzina, kā darbojas OAuth, lai lietotājiem nodrošinātu viegli lietojamu un labi integrētu pakalpojumu.

Ideja ir atļaut klienta lietojumprogrammām ierobežotu piekļuvi lietotāja informācijai, nekad neizmantojot lietotāja akreditācijas datus vai paroli. OAuth sistēma ir atbildīga par apmaiņu, kas nepieciešama, pirms lietojumprogramma iegūst jūsu informāciju.

Pieņemsim, ka vēlaties reģistrēties Dev.lai (kas ir lieliska vieta, kur izstrādātāji var apmainīties ar idejām), viņi ļauj jums reģistrēties, izmantojot savu GitHub kontu. Kā tas notiek? Kā viņi zinātu, ka jums pieder GitHub konts, ar kuru reģistrējaties?

Vēl svarīgāk ir tas, kā jūs nodrošināt, ka Dev.to nepārkāpj robežas, kad runa ir par jūsu informāciju, kas tiek glabāta GitHub?

OAuth dalībnieki

Mēs paliksim pie Atom redaktora GitHub spraudņa piemēra, kas ļauj izstrādātājiem virzīt kodu uz GitHub tieši, izmantojot Atom saskarni. Iemesls tam ir tas, ka GitHub neslēpj detaļas aiz ainas, un jūs redzat, kas notiek zem pārsega.

Pirms mēs nonākam OAuth darba sīkumos. Uzstādīsim posmu, atzīstot visus apmaiņas dalībniekus:

1. Resursa īpašnieks vai lietotājs: Šis lietotājs ir tas, kura konta informācijai ir jāpiekļūst (lasīt un / vai rakstīt), lai tā darbotos ar lietojumprogrammu.
2. Klients: Šī ir lietojumprogramma, kas meklē jūsu atļauju piekļūt jūsu informācijai no cita pakalpojuma. Mūsu piemērā Atom redaktors ir klients.
3. Resurss: Resurss ir jūsu faktiskā informācija, kas atrodas serveros kādā attālā vietā. Tam var piekļūt, izmantojot API, ja klientam ir piešķirtas atbilstošas ​​atļaujas.
4. Autorizācijas serveris: Arī saskarne ar API starpniecību. Šo serveri uztur pakalpojumu sniedzējs (mūsu piemērā GitHub). Gan autorizācijas serveris, gan resursu serveris tiek dēvēti par API, jo tos pārvalda viena entītija, šajā gadījumā GitHub, un klienta izstrādātājam tiek pakļauti API.

OAuth reģistrācija

Process sākas, kad tiek izstrādāta klienta lietojumprogramma. Jūs varat doties uz resursu nodrošinātāju un reģistrēties viņu izstrādātāja portālā vai vietnes API sadaļā. Jums būs jānorāda arī atzvanīšanas URL, kur lietotājs tiktu novirzīts pēc pieņemšanas vai noraidīšanas, lai lietotnei piešķirtu nepieciešamās atļaujas.

Piemēram, ja dodaties uz GitHub → Iestatījumi → Izstrādātāja iestatījumi un noklikšķiniet uz “Reģistrēt jaunu lietojumprogrammu”. Tas jums nodrošinātu Klienta ID ko var publiskot un a Klienta noslēpums kas izstrādātāju organizācijai ir jāglabā noslēpumā.

Pēc tam, kad klienta ID un noslēpums ir sniegts jums, izstrādātājam, jums jābūt glabājiet tos drošībā, jo autorizācijas serveris tos vairs neparādīs. Tas pats attiecas uz jebkuriem citiem žetoniem, kas tiktu mesti apkārt (Vairāk par žetoniem vēlāk).

OAuth 2 darbplūsma

Jūs esat reģistrējis savu pieteikumu. Tas ir izstrādāts un pārbaudīts, un tagad lietotāji ir gatavi to izmantot. Jaunam lietotājam, reģistrējoties jūsu pakalpojumā, tiks parādīta opcija “Pierakstīties, izmantojot GitHub”. Šis ir pirmais solis.

1. darbība: autorizācijas pieprasījums

Autorizācijas pieprasījums ir tā daļa, kurā ar resursa vietni tiek atvērts jauns logs (vai līdzīga uzvedne) un tiek lūgts lietotājiem pieteikties. Ja jūs jau esat pieteicies šajā ierīcē, šī darbība tiek izlaista un GitHub vienkārši jautā, vai vēlaties piešķirt piekļuvi Atom klienta lietotnei. Atom gadījumā tas ir daudz pārredzamāk, jo viņi lūdz jūs manuāli doties uz GitHub vietni un piešķirt viņiem atļauju.

Apmeklējot URL, jums tiek lūgta atļauja.

Ievērojiet, ka vietrādis URL ir GitHub droša (HTTPS) vietne.Inc. Tagad jūs, lietotājs, varat būt drošs, ka tieši mijiedarbojaties ar GitHub. Atoms vienkārši gaida, gluži no ceļa.

Atšķirībā no Atom, lielākā daļa klientu lietotņu automātiski ielādē pieteikšanās vai atļauju lapu. Lai gan tas ir ļoti ērti, to var arī ļaunprātīgi izmantot, ja klienta lietotne nolemj atvērt pikšķerēšanas saiti. Lai no tā izvairītos, jums vienmēr jāpārbauda URL, uz kuru esat novirzīts, un jāpārliecinās, ka tas ir pareizs URL un izmanto HTTPS protokolu.

2. darbība: autorizācijas dotācijas iegūšana

Lai paziņotu Atom klientam, jums tiek piešķirts marķieris (autorizācijas piešķīrums), kas pēc tam tiek iesniegts Atom klientam.

Kad lietotājs to izdarīs, lietotāja darbs būs pabeigts. (Faktiski parasts lietotājs pat nezina par autorizācijas piešķiršanas apmaiņu. GitHub piemērs tika izvēlēts, lai parādītu, ka tā notiek).

3. darbība: piekļuves pilnvaras iegūšana

Autorizācijas piešķīrums joprojām nav vienība, kas klientam piešķir piekļuvi lietotāja informācijai. To iegūst, izmantojot kaut ko, ko sauc par piekļuves marķieri. Kuru klienta lietotne mēģinās iegūt šajā solī.

Lai to izdarītu, klientam tagad autorizācijas serverim būs jāsniedz autorizācijas piešķiršana kopā ar savas identitātes apliecinājumu. Identitāte tiek pārbaudīta, izmantojot klienta ID un klienta noslēpumu, kas klienta lietotnei tika piešķirts iepriekš.

Identitātes pārbaude tiek veikta, lai pārliecinātos, ka lietotājs netiek maldināts izmantot ļaunu lietotni, kas izliekas par likumīgu lietotni. Piemēram, ja kāds nolemj nosaukt savu izpildāmo failu kā Atom ar tādu pašu nosaukumu, logotipu un funkcionalitāti, lietotājs var maldināt piekļuves piešķiršanu klientam, kas var ļaunprātīgi izmantot jūsu informāciju. Viņi var snoop vai pat rīkoties bez jūsu piekrišanas. Autorizācijas serveris nodrošina, ka klients patiešām ir tāds, kāds tas šķiet tā lietotājiem.

Kad identitāte ir pārbaudīta un autorizācijas piešķīrums ir pieņemts, autorizācijas serveris klienta lietotnei izmet marķieri. Padomājiet par marķieri kā par lietotājvārda un paroles kombināciju, ko var piešķirt resursu serverim, lai piekļūtu konkrētam aizsargātam resursam, kuram resursa īpašnieks jums ļāva piekļūt.

Visbeidzot, izmantojot šo marķieri, lietotne tagad var piekļūt nepieciešamajai lietotāja informācijai un citiem resursu servera resursiem.

Ievērojiet, kā visā šajā apmaiņā tiek izmantots faktiskais lietotājvārds un parole, ja tie nekad nav kopīgoti ar klientu? Tas ir OAuth skaistums. Tā vietā, lai piešķirtu lietotājvārdu un paroles, kas lietotnei piešķirtu visu piekļuvi resursam, tā vietā tiek izmantoti marķieri. Un marķieris var iegūt tikai ierobežotu piekļuvi resursam.

Atļauju atsaukšana

Pieņemsim, ka zaudējat piekļuvi savai ierīcei, kurā atradās autorizētā klienta lietotne. Varat pieteikties GitHub un doties uz Iestatījumi → Programmas → Autorizētās OAuth lietotnes, lai atsauktu autorizācijas piešķiršanu un piekļuves pilnvaru. Es darīšu to pašu, jo iepriekšējos ekrānuzņēmumos autorizācijas piešķīrums tika publiski parādīts.

Tagad, kad jums ir putna lidojuma skatījums uz to, kā OAuth 2.Šeit varat uzzināt vairāk par autorizācijas piešķiršanu un citu sīkāku informāciju par protokolu un par to, kā tiek veikti API izsaukumi.