Çfarë është autentikimi? Login, sesionet dhe OAuth të shpjeguara

Autentikimi është mënyra si një aplikacion konfirmon kush është një përdorues — zakonisht duke kontrolluar diçka që ai e di (një fjalëkalim), diçka që ka (një kod të dërguar në telefon ose email) ose një identitet nga një shërbim tjetër i besuar (si „Hyr me Google“). Pasi një përdorues është autentikuar, aplikacioni e mban mend me një sesion ose token, që të mos duhet të hyjë përsëri në çdo faqe. Të vendosësh çfarë mund të bëjë ai përdorues i njohur është një hap tjetër, i quajtur autorizim.

Pse ka rëndësi kur ndërtoni me AI

Shtimi i hyrjes është një nga kërkesat më të shpeshta që u bëhen ndërtuesve me AI, dhe një nga më të lehtat për ta gabuar në mënyrë të padukshme. Një faqe hyrjeje është e thjeshtë për t'u gjeneruar. Pjesa e vështirë është gjithçka rreth saj:

• A ruhen fjalëkalimet në mënyrë të sigurt?
• A kontrollon çdo faqe private dhe çdo endpoint i API-t me të vërtetë kush po kërkon?
• A mund të shohë një klient i kyçur të dhënat e një klienti tjetër duke ndryshuar një numër në URL?
• Çfarë ndodh kur dikush harron fjalëkalimin?

Një aplikacion mund të duket plotësisht i sigurt dhe ende të dështojë në secilën nga këto. Të kuptuarit e pjesëve lëvizëse ju lejon të bëni pyetjet e duhura dhe të testoni gjërat e duhura.

Një analogji e përditshme

Mendoni për regjistrimin në një hotel.

Në recepsion tregoni dokumentin tuaj. Kjo është autentikimi: të provoni kush jeni. Recepsionisti pastaj ju jep një kartelë çelësi. Ajo kartelë është sesioni juaj: për gjithë qëndrimin nuk tregoni më dokument; e prekni kartelën.

Kartela hap dhomën tuaj, palestrën dhe ashensorin për katin tuaj — por jo dhomat e mysafirëve të tjerë apo zyrën e stafit. Kjo është autorizimi: çfarë qasjeje lejon identiteti juaj. Nëse e humbni kartelën, hoteli mund ta çaktivizojë te recepsioni (revokimi i sesionit). Kur largoheni, ajo përfundon së funksionuari (dalja nga llogaria, ose skadimi).

„Hyr me Google“ është si një hotel që pranon një letër nga një partner i besuar që thotë „ky është kush është“, në vend që vetë të kontrollojë dokumentin tuaj.

Metodat kryesore të hyrjes

Si duhet të ruhen fjalëkalimet

Një aplikacion i sigurt nuk ruan kurrë fjalëkalimin tuaj aktual. Në vend të kësaj ruan një hash: rezultatin e një funksioni njëdrejtimësh që e shndërron fjalëkalimin në një varg fiks. Kur hyni, aplikacioni e hash-on atë që shkruat dhe e krahason rezultatin me hash-in e ruajtur.

Dy detaje e bëjnë këtë të sigurt:

• Një kripë (salt) — një vlerë e rastësishme e shtuar te çdo fjalëkalim para hash-imit, kështu që dy persona me të njëjtin fjalëkalim marrin hash-e të ndryshme, dhe tabelat e para-llogaritura janë të padobishme.
• Një algoritëm i ngadaltë i krijuar për fjalëkalime — si Argon2, bcrypt ose scrypt. Hash-et me qëllim të përgjithshëm si MD5 ose SHA-256 janë shumë të shpejta në vetvete; sulmuesit mund të provojnë miliarda hamendësime.

Hash-imi nuk është e njëjta gjë me enkriptimin. Të dhënat e enkriptuara mund të dekriptohen me një çelës; një hash fjalëkalimi është projektuar që të mos jetë fare i kthyeshëm.

Sesionet kundrejt tokenave

Pas hyrjes, aplikacioni duhet t'ju njohë në çdo kërkesë. Ka dy qasje të zakonshme.

Për cookie-t, tre cilësime kanë rëndësi: HttpOnly (JavaScript në faqe nuk mund ta lexojë cookie-n), Secure (dërgohet vetëm përmes HTTPS) dhe SameSite (kufizon dërgimin e tij te kërkesat nga faqe të tjera). Ruajtja e tokenave në localStorage të shfletuesit është e zakonshme, por i ekspozon ata ndaj çdo skripte që ekzekutohet në faqe.

OAuth dhe „Hyr me Google“

OAuth 2.0 është një standard për autorizim të deleguar: lejon një aplikacion të marrë qasje të kufizuar te llogaria juaj në një shërbim tjetër — le të themi, të lexojë kalendarin tuaj të Google — pa e parë kurrë fjalëkalimin tuaj të Google. Ju dërgoheni te Google, miratoni leje specifike (quajtura scopes), dhe Google i jep aplikacionit një token vetëm për ato leje.

OAuth në vetvete u projektua për të dhënë qasje, jo për të thënë kush jeni. OpenID Connect (OIDC) është një shtresë mbi OAuth 2.0 që shton identitetin, dhe kjo është ajo që përdor „Hyr me Google“ ose „Hyr me Apple“. Për ta konfiguruar, regjistroni aplikacionin te ofruesi dhe merrni një client ID dhe një client secret; sekreti mbetet në serverin tuaj.

Një shembull i punuar: hyrja për një portal klientësh

Le të themi se po ndërtoni një portal ku klientët e një agjencie dizajni shohin projektet dhe faturat e tyre.

• Autentikimi: klientët hyjnë me email dhe lidhje magjike, kështu që nuk ka fjalëkalime për t'u menaxhuar. Stafi i agjencisë hyn me llogari Google Workspace.
• Rolet: çdo përdorues ka një rol — client ose staff.
• Rregullat e autorizimit:

• Ku zbatohet: në server, për çdo kërkesë. Serveri kërkon përdoruesin e kyçur, pastaj kthen vetëm projektet ku project.company_id përputhet me kompaninë e përdoruesit. Fshehja e butonit „Shëno të paguar“ nuk mjafton — vetë endpoint-i duhet të refuzojë.

Termat e zakonshëm të shpjeguar

Gabime dhe keqkuptime të zakonshme

• Kontrollimi i lejeve vetëm në faqe. Nëse shfletuesi fshih një buton por API-ja nuk kontrollon, çdokush mund ta thërrasë API-n drejtpërdrejt.
• Besimi te ID-të nga URL-ja. /invoices/1042 duhet të kontrollojë që fatura 1042 i përket përdoruesit të kyçur.
• Krijimi i kriptografisë vetë. Përdorni biblioteka ose ofrues të njohur; mos e lejoni AI-në të shpikë një skemë hash-imi.
• Rivendosje e dobët fjalëkalimi. Lidhjet e rivendosjes duhet të përdoren vetëm një herë, të skadojnë shpejt dhe të mos zbulojnë nëse një email ka llogari.
• Ngatërrimi i hyrjes tuaj me atë të ndërtuesit. Përdoruesit e aplikacionit tuaj janë të veçantë nga llogaria juaj te mjeti me të cilin ndërtoni.
• Pa kufizim të shpejtësisë në hyrje. Pa të, sulmuesit mund të provojnë fjalëkalime pa fund.

Çfarë t'i kërkoni ndërtuesit tuaj me AI

• „Shto regjistrim dhe hyrje duke përdorur [një bibliotekë ose ofrues të njohur]. Mos shkruaj hash-im fjalëkalimi vetë.“
• „Ruaji fjalëkalimet e hash-uara me bcrypt ose Argon2.“
• „Përdor cookie-t HttpOnly dhe Secure për sesionin.“
• „Shto role: admin dhe member. Listo çdo endpoint dhe cilët role mund ta thërrasin.“
• „Sigurohu në server që përdoruesit mund të lexojnë dhe ndryshojnë vetëm të dhënat e tyre. Pastaj më trego si e kontrolluat.“
• „Shto rivendosje fjalëkalimi me lidhje që përdoren vetëm një herë dhe skadojnë pas një ore.“
• „Kufizo shpejtësinë e tentativave të hyrjes.“

Pastaj testoni vetë: krijoni dy llogari dhe provoni të arrini të dhënat e njërës ndërsa jeni kyçur si tjetra. Udhëzuesi ynë për shtimin e hyrjes dhe lista e kontrollit të sigurisë shkojnë më tej.

Autentikimi në Mythex

Mythex nuk ofron një produkt të integruar autentikimi për përdoruesit e aplikacionit tuaj; ju zgjidhni një qasje — email dhe fjalëkalim të ruajtur në bazën e të dhënave të projektit tuaj, ose SDK-në e një ofruesi të hostuar — dhe i kërkoni agjentit ta shtojë. Çelësat e ofruesit vendosen te sekretet e projektit, jo në chat. Kjo është e ndarë nga mënyra si hyni vetë në Mythex. Recetë e dokumentacionit për shtimin e hyrjes te aplikacioni juaj ka një kërkesë fillestare që mund ta përshtatni, dhe çfarë është një API shpjegon ku jetojnë ato kontrolle në server.

Pyetje