Mis on autentimine? Sisselogimine, sessioonid ja OAuth

Autentimine on see, kuidas rakendus kinnitab, kes kasutaja on – tavaliselt kontrollides midagi, mida kasutaja teab (parooli), midagi, mis tal on (koodi, mis saadeti telefonile või e-posti aadressile), või identiteeti teisest usaldusväärsest teenusest (näiteks „Logi sisse Google'iga”). Kui kasutaja on autentitud, mäletab rakendus teda sessiooni või žetooni abil, nii et ta ei peaks igal lehel uuesti sisse logima. Otsus, mida see tuntud kasutaja tohib teha, on eraldi samm, mida nimetatakse volituste kontrolliks (authorization).

Miks see AI-ga ehitamisel oluline on

Sisselogimise lisamine on üks levinumaid päringuid, mida inimesed AI ehitajale esitavad, ja üks lihtsamaid asju valesti teha. Sisselogimisvormi on lihtne genereerida. Raske osa on kõik selle ümber:

• Kas paroole hoitakse turvaliselt?
• Kas iga privaatne leht ja iga API lõpp-punkt tegelikult kontrollib, kes päringu teeb?
• Kas sisselogitud klient näeb teise kliendi andmeid, muutes URL-is numbrit?
• Mis juhtub, kui keegi unustab parooli?

Rakendus võib välja näha täiesti turvaline ja ebaõnnestuda kõigis neis punktides. Kui mõistad, mis osad on liikuvad, oskad esitada õigeid küsimusi ja õigeid asju testida.

Igapäevane võrdlus

Mõtle hotelli sisseregistreerimisele.

Vastuvõtulauas näitad isikut tõendavat dokumenti. See on autentimine: tõestad, kes oled. Retseptsionist annab sulle kaardi. See kaart on sinu sessioon: kogu viibimise ajal ei pea sa dokumenti uuesti näitama, vaid puudutad kaarti.

Kaart avab su toa, spordisaali ja su korruse lifti – aga mitte teiste külaliste tube ega personaliruumi. See on volituste kontroll: mida sinu isik tohib kasutada. Kui kaotad kaardi, saab hotell selle vastuvõtus deaktiveerida (sessiooni tühistamine). Väljaregistreerimisel see lakkab töötamast (väljalogimine või aegumine).

„Logi sisse Google'iga” on nagu hotell, mis aktsepteerib usaldusväärse partneri kirja, mis ütleb „see on see isik”, selle asemel et kontrollida su dokumenti ise.

Peamised sisselogimismeetodid

Kuidas paroole tuleks salvestada

Turvaline rakendus ei salvesta kunagi sinu tegelikku parooli. Selle asemel salvestab ta räsi: ühesuunalise funktsiooni väljundi, mis muudab parooli kindlapikkuseks stringiks. Sisselogimisel räsib rakendus sisestatud väärtuse ja võrdleb tulemust salvestatud räsiga.

Kaks detaili teevad selle turvaliseks:

• Sool – juhuslik väärtus, mis lisatakse igale paroolile enne räsimist, nii et kaks inimest sama parooliga saavad erinevad räsid ning eelarvutatud otsingutabelid on kasutud.
• Paroolidele mõeldud aeglane algoritm – näiteks Argon2, bcrypt või scrypt. Üldotstarbelised räsid nagu MD5 või SHA-256 on üksi liiga kiired; ründajad saaksid miljardeid arvamisi proovida.

Räsimine ei ole sama mis krüpteerimine. Krüpteeritud andmeid saab võtmega dekrüpteerida; paroolirääsi on mõeldud üldse mitte tagasi pööratavaks.

Sessioonid vs žetoonid

Pärast sisselogimist peab rakendus sind iga päringu puhul ära tundma. On kaks levinud lähenemist.

Küpsiste puhul on kolm seadet olulised: HttpOnly (lehel olev JavaScript ei saa küpsist lugeda), Secure (saadetakse ainult HTTPS-i kaudu) ja SameSite (piirab saatmist päringutele teistelt saitidelt). Žetoonide hoidmine brauseri localStorage'is on tavaline, kuid see avab need igale lehel töötavale skriptile.

OAuth ja „Logi sisse Google'iga”

OAuth 2.0 on standard delegeeritud volituste jaoks: see laseb rakendusel saada piiratud juurdepääsu sinu kontole teises teenuses – näiteks lugeda sinu Google'i kalendrit – ilma et ta kunagi näeks sinu Google'i parooli. Sind suunatakse Google'isse, kinnitad konkreetsed õigused (mida nimetatakse scope'ideks) ning Google annab rakendusele žetooni ainult nende õiguste jaoks.

OAuth ise oli loodud juurdepääsu andmiseks, mitte selleks, et öelda, kes sa oled. OpenID Connect (OIDC) on OAuth 2.0 peale ehitatud kiht, mis lisab identiteedi – seda kasutab „Logi sisse Google'iga” või „Logi sisse Apple'iga”. Seadistamiseks registreerid oma rakenduse pakkujas ja saad kliendi ID ning kliendi saladuse; saladus jääb sinu serverisse.

Näide: sisselogimine kliendiportaali

Oletame, et ehitad portaali, kus disainiagentuuri kliendid näevad oma projekte ja arveid.

• Autentimine: kliendid logivad sisse e-posti ja ühekordse lingiga, nii et paroole pole vaja hallata. Agentuuri töötajad logivad sisse Google Workspace'i kontodega.
• Rollid: igal kasutajal on roll – client või staff.
• Volituste reeglid:

• Kus seda jõustatakse: serveris, iga päringu puhul. Server leiab sisselogitud kasutaja ja tagastab ainult need projektid, kus project.company_id vastab kasutaja ettevõttele. Nupu „Märgi tasutuks” peitmine ei piisa – lõpp-punkt peab ise keelduma.

Levinud mõisted selgitatult

Levinud vead ja väärarusaamad

• Õiguste kontrollimine ainult lehel. Kui brauser peidab nupu, aga API ei kontrolli, saab keegi API-t otse kutsuda.
• URL-ist tulevate ID-de usaldamine. /invoices/1042 peab kontrollima, et arve 1042 kuulub sisselogitud kasutajale.
• Oma krüptograafia kirjutamine. Kasuta tuntud teeke või pakkujaid; ära lase AI-l välja mõelda räsimisskeemi.
• Nõrk parooli lähtestamine. Lähtestuslingid peaksid olema ühekordsed, kiiresti aeguvad ega tohi paljastada, kas e-posti aadressiga on konto.
• Oma sisselogimise segamine ehitaja omaga. Su rakenduse kasutajad on eraldi sinu kontost tööriistas, millega ehitad.
• Sisselogimise piiramata katsed. Ilma määrata kiirusepiiranguta võivad ründajad parooli lõputult proovida.

Mida küsida oma AI ehitajalt

• „Lisa registreerimine ja sisselogimine, kasutades [tuntud teeki või pakkujat]. Ära kirjuta oma paroolide räsimist.”
• „Salvesta paroolid räsitult, kasutades bcrypt'i või Argon2.”
• „Kasuta sessiooniküpsiste jaoks HttpOnly ja Secure küpsiseid.”
• „Lisa rollid: admin ja member. Loetle iga lõpp-punkt ja see, milliseid rolle see lubab kutsuda.”
• „Jõusta serveris, et kasutajad saavad lugeda ja muuta ainult oma kirjeid. Seejärel näita, kuidas kontrollisid.”
• „Lisa parooli lähtestamine ühekordsete linkidega, mis aeguvad tunni pärast.”
• „Piira sisselogimiskatseid kiiruspiiranguga.”

Seejärel testi ise: loo kaks kontot ja proovi ühe kasutaja andmetele ligi pääseda, olles sisse logitud teisena. Juhend sisselogimise lisamiseks ja turvakontrollnimekiri lähevad kaugemale.

Autentimine Mythexis

Mythex ei paku sinu rakenduse kasutajatele sisseehitatud autentimistoodet; valid lähenemise – e-posti ja parooli projekti andmebaasis või hostitud pakkuja SDK – ning palud agendil selle lisada. Pakkuja võtmed lähevad projekti saladustesse, mitte vestlusse. See on eraldi sellest, kuidas ise Mythexisse sisse logid. Dokumentatsiooni retsept rakenduse sisselogimise lisamine sisaldab algusprompti, mida saad kohandada, ja mis on API selgitab, kus need serveripoolsed kontrollid elavad.

Küsimused