Kas ir autentifikācija? Pieteikšanās, sesijas un OAuth izskaidrots

Autentifikācija ir veids, kā lietotne apstiprina, kas ir lietotājs — parasti pārbaudot kaut ko, ko viņš zina (paroli), kaut ko, kam viņam ir piekļuve (kodu, kas nosūtīts uz tālruni vai e-pastu), vai identitāti no cita uzticama pakalpojuma (piemēram, „Pieteikties ar Google”). Kad lietotājs ir autentificēts, lietotne viņu atceras ar sesiju vai marķieri, lai viņam nevajadzētu pieteikties katrā lapā. Lēmums, ko šis zināmais lietotājs drīkst darīt, ir atsevišķs solis, ko sauc par autorizāciju.

Kāpēc tas ir svarīgi, veidojot ar MI

Pieteikšanās pievienošana ir viens no biežākajiem pieprasījumiem MI lietotņu veidotājam, un viens no vieglākajiem, ko nepamanot izdarīt nepareizi. Pieteikšanās lapu ir viegli ģenerēt. Grūtākais ir viss, kas to ieskauj:

• Vai paroles tiek glabātas droši?
• Vai katra privātā lapa un katrs API galapunkts tiešām pārbauda, kas pieprasa piekļuvi?
• Vai pieteicies klients var redzēt cita klienta datus, mainot skaitli URL?
• Kas notiek, kad kāds aizmirst paroli?

Lietotne var izskatīties pilnīgi droša, bet neizturēt nevienu no šīm pārbaudēm. Kad saprotat darbīgās daļas, varat uzdot pareizos jautājumus un pārbaudīt pareizās lietas.

Ikdienas salīdzinājums

Iedomājieties, ka reģistrējaties viesnīcā.

Pie reģistratūras jūs parādāt personas apliecinājumu. Tā ir autentifikācija: pierādīt, kas jūs esat. Administrators pēc tam jums izsniedz atslēgkarti. Šī karte ir jūsu sesija: visu uzturēšanās laiku jums vairs nav jārāda apliecinājums; jūs vienkārši piesienat karti.

Karte atver jūsu numuru, sporta zāli un lifta piekļuvi jūsu stāvam — bet ne citu viesu numurus vai personāla telpu. Tā ir autorizācija: kam jūsu identitātei ir atļauta piekļuve. Ja karti pazaudējat, viesnīca to var deaktivizēt pie galda (sesijas atsaukšana). Kad izrakstāties, karte pārstāj darboties (izrakstīšanās vai termiņa beigas).

„Pieteikties ar Google” ir kā viesnīca, kas pieņem uzticama partnera vēstuli ar apgalvojumu „šī ir tā persona”, nevis pārbauda jūsu apliecinājumu pati.

Galvenās pieteikšanās metodes

Kā jāglabā paroles

Droša lietotne nekad neglabā jūsu īsto paroli. Tā vietā tā glabā jaucējvērtību — vienvirziena funkcijas rezultātu, kas paroli pārvērš fiksētā virknē. Kad pieteicaties, lietotne jaucē ievadīto un salīdzina rezultātu ar saglabāto jaucējvērtību.

Divas detaļas padara to drošu:

• Sāls — nejaušs vērtums, kas pievienots katrai parolei pirms jaukšanas, tāpēc diviem cilvēkiem ar vienādu paroli būs dažādas jaucējvērtības, un iepriekš sagatavotas meklēšanas tabulas nav noderīgas.
• Lēns algoritms, kas paredzēts parolēm — piemēram, Argon2, bcrypt vai scrypt. Vispārīgas jaucējvērtības, piemēram, MD5 vai SHA-256, pašas par sevi ir pārāk ātras; uzbrucēji var izmēģināt miljardiem minējumu.

Jaukšana nav tas pats, kas šifrēšana. Šifrētus datus var atšifrēt ar atslēgu; paroles jaucējvērtība ir veidota tā, lai to nemaz nevarētu atgriezt.

Sesijas pret marķieriem

Pēc pieteikšanās lietotnei katrā pieprasījumā jāatpazīst jūs. Ir divas bieži lietotas pieejas.

Sīkdatnēm svarīgi ir trīs iestatījumi: HttpOnly (lapas JavaScript nevar nolasīt sīkdatni), Secure (sūta tikai pa HTTPS) un SameSite (ierobežo sūtīšanu pieprasījumos no citām vietnēm). Marķieru glabāšana pārlūkprogrammas localStorage ir izplatīta, taču tā tos pakļauj jebkuram skriptam, kas darbojas lapā.

OAuth un „Pieteikties ar Google”

OAuth 2.0 ir standarts deleģētai autorizācijai: tas ļauj lietotnei saņemt ierobežotu piekļuvi jūsu kontam citā pakalpojumā — teiksim, lasīt jūsu Google kalendāru — bez jebkādas iespējas redzēt jūsu Google paroli. Jūs tiekat novirzīts uz Google, apstiprināt konkrētas atļaujas (sauktas par scopes), un Google lietotnei izdod marķieri tikai šīm atļaujām.

OAuth pats par sevi tika veidots, lai piešķirtu piekļuvi, nevis lai paziņotu, kas jūs esat. OpenID Connect (OIDC) ir slānis virs OAuth 2.0, kas pievieno identitāti; tieši to izmanto „Pieteikties ar Google” vai „Pieteikties ar Apple”. Lai to uzstādītu, jūs reģistrējat lietotni pie pakalpojumu sniedzēja un saņemat klienta ID un klienta noslēpumu; noslēpums paliek jūsu serverī.

Praktisks piemērs: pieteikšanās klientu portālam

Pieņemsim, ka veidojat portālu, kur dizaina aģentūras klienti redz savus projektus un rēķinus.

• Autentifikācija: klienti pieslēdzas ar e-pastu un burvju saiti, tāpēc nav paroļu, ko pārvaldīt. Aģentūras darbinieki pieslēdzas ar Google Workspace kontiem.
• Lomas: katram lietotājam ir loma — client vai staff.
• Autorizācijas noteikumi:

• Kur tas tiek ieviests: serverī, katrā pieprasījumā. Serveris atrod pieteikušos lietotāju un atgriež tikai tos projektus, kuros project.company_id sakrīt ar lietotāja kompāniju. Pogas „Atzīmēt kā apmaksātu” paslēpšana nav pietiekama — pats galapunkts jānoraida.

Izskaidroti biežākie termini

Biežākās kļūdas un maldi

• Atļauju pārbaude tikai lapā. Ja pārlūkprogramma paslēpj pogu, bet API nepārbauda, ikviens var izsaukt API tieši.
• Uzticēšanās ID no URL. /invoices/1042 jāpārbauda, vai rēķins 1042 pieder pieteiktajam lietotājam.
• Savas kriptogrāfijas veidošana. Izmantojiet labi zināmas bibliotēkas vai pakalpojumu sniedzējus; neļaujiet MI izgudrot jaukšanas shēmu.
• Vāja paroles atiestatīšana. Atiestatīšanas saitēm jābūt vienreizējām, jābeidzas ātri un nedrīkst atklāt, vai e-pastam ir konts.
• Pieteikšanās sajaukšana ar veidotāja pieteikšanos. Jūsu lietotnes lietotāji ir atsevišķi no jūsu konta rīkā, ar ko veidojat.
• Nav pieteikšanās ierobežojuma. Bez tā uzbrucēji var nebeidzami mēģināt paroles.

Ko lūgt savam MI veidotājam

• „Pievieno reģistrāciju un pieteikšanos, izmantojot [labi zināmu bibliotēku vai pakalpojumu sniedzēju]. Nerakstīt pielāgotu paroļu jaukšanu.”
• „Glabā paroles kā jaucējvērtības, kas veidotas ar bcrypt vai Argon2.”
• „Sesijai izmanto HttpOnly, Secure sīkdatnes.”
• „Pievieno lomas: admin un member. Uzskaiti katru galapunktu un to, kuras lomas drīkst to izsaukt.”
• „Serverī nodrošini, ka lietotāji var lasīt un labot tikai savus ierakstus. Pēc tam parādi, kā to pārbaudīji.”
• „Pievieno paroles atiestatīšanu ar vienreizējām saitēm, kas beidzas pēc vienas stundas.”
• „Ierobežo pieteikšanās mēģinājumu biežumu.”

Pēc tam pārbaudiet paši: izveidojiet divus kontus un mēģiniet piekļūt vienam konta datiem, esot pieteicies ar otru. Mūsu ceļvedis par pieteikšanās pievienošanu un drošības kontrolsaraksts iet tālāk.

Autentifikācija Mythex

Mythex nenodrošina iebūvētu autentifikācijas produktu jūsu lietotnes lietotājiem; jūs izvēlaties pieeju — e-pastu un paroli, kas glabājas jūsu projekta datubāzē, vai hostēta pakalpojumu sniedzēja SDK — un lūdzat aģentu to pievienot. Pakalpojumu sniedzēju atslēgas ieliek projekta noslēpumos, nevis čatā. Tas ir atsevišķi no tā, kā jūs pieslēdzaties pašam Mythex. Dokumentāciju receptē par pieteikšanās pievienošanu lietotnei ir sākuma uzvedne, ko varat pielāgot, un kas ir API paskaidro, kur atrodas šīs servera puses pārbaudes.

Jautājumi