Kuidas lisada oma rakendusse sisselogimine: paroolid, võlulingid, Google ja rollid

Sisselogimise lisamiseks rakendusse vali meetod — e-post ja parool, võlulingid (ühekordne sisselogimislink, mis saadetakse e-postiga) või „Logi sisse Google'iga“ — ning rakenda see tõestatud autentimisteegi või hostitud teenusega, mitte nullist. Seejärel otsusta, mida iga kasutajatüüp tohib teha (rollid), ja jõusta see serveris igal lehel ja API päringul. Sessioonid peaksid kasutama turvalisi küpsiseid, aeguma ja lõppema korrektselt väljalogimisel.

See juhend käib läbi iga valiku ja detailid, mis eristavad toimivat sisselogimist turvalisest. Nende aluseks olevate mõistete kohta vt mis on autentimine.

Otsusta esmalt: kas sul üldse on vaja sisselogimist?

Sisselogimine lisab takistusi ja vastutust. Seda on vaja, kui:

• Kasutajatel on privaatseid andmeid (nende broneeringud, dokumendid, arved)
• Kasutajad saavad muuta asju, mida teised näevad
• Võtad juurdepääsu eest tasu
• Erinevad inimesed vajavad erinevaid õigusi (omanik vs töötaja vs klient)

Sa ei pruugi seda vajada turundusleht, avalik kataloog või vorm, mis lihtsalt saadab sulle e-kirja. Ootelistiga ei vaja kontosid; e-posti väli on piisav.

Neli levinud sisselogimismeetodit

Mitu rakendust ühendavad kaks: Google'iga sisselogimine ja e-posti võlulingid on populaarne paar, mis katab enamiku inimesi ilma paroole hoidmata.

E-post ja parool

Kui pakud paroole, on need mittekõõrduvad nõuded:

• Räsi paroole aeglase paroolide räsimisalgoritmiga. OWASP-i paroolide hoidmise juhend soovitab Argon2id-d, alternatiivina scrypt, bcrypt või PBKDF2. Ära hoia paroole lihtteksti ega kiire üldise räsiga.
• Parooli lähtestamine kasutab juhuslikku, ühekordset ja aegunud linki, mis saadetakse kinnitatud e-posti.
• Ära näita, millistel e-postidel on kontod. „Kui see e-post on registreeritud, oleme saatnud lähtestamislingi“ on parem kui „Kontot ei leitud“.
• Piira päringuid sisselogimisel ja lähtestamisel, et aeglustada parooli arvamist.
• Luba pikki paroole ja paroolihaldureid; jäta vahele reeglid, mis sunnivad kummalisi märgikombinatsioone.

Võlulingid ja ühekordsed koodid

Võlulink on sisselogimislink, mis saadetakse kasutajale e-kirjaga. Sellel klõpsamine logib kasutaja sisse.

• Lingid ja koodid aeguvad kiiresti ja töötavad ainult üks kord.
• Link peaks logima kasutaja sisse seadmes, kus ta klõpsas, ning tokenit ei tohi jääda logidesse ega analüütikatööriistadesse.
• Vajad usaldusväärset e-kirjade saatmist — vt kuidas saata e-kirju oma rakendusest. Testi Gmaili ja Outlookiga ning kontrolli rämpsposti kaustu.

Sisselogimine Google'iga (ja teiste OAuth-pakkujatega)

„Logi sisse Google'iga“ kasutab OAuth-i ja OpenID Connecti: Google kinnitab, kes kasutaja on, ja ütleb su rakendusele tema e-posti ja nime. Seadistus Google Cloud Consoles'i jaotises Google Auth Platform, seisuga september 2026, on järgmine:

1. Loo või vali projekt ja täida lehel Branding — mida kasutajad nõusoleku ekraanil näevad (rakenduse nimi, toe e-post, logo).
2. Lehel Clients loo klient tüübiga „Web application“.
3. Lisa authorized JavaScript origins ja redirect URI-d — täpsed aadressid, kus su rakendus töötab ja kuhu Google kasutajad pärast sisselogimist tagasi saadab.
4. Salvesta kliendi ID ja kliendi saladus rakenduse saladustesse.

Asjad, mis tavaliselt valesti lähevad, vastavalt Google'i OAuth dokumentatsioonile:

• redirect_uri_mismatch: suunamisaadress peab täpselt klappima, sh http vs https, suur- ja väiketähed ning lõpus olev kaldkriips. Lisa üks oma eelvaate aadressile ja üks oma avalikule domeenile.
• HTTPS on nõutud: suunamis-URI-d peavad kasutama HTTPS-i, välja arvatud localhost arenduse ajal.
• state parameetrit tuleks kontrollida tagasituleku ajal, et kaitsta saitidevahelise päringu võltsimise eest. Head teegid teevad seda sinu eest.

Kui küsid ainult põhilist sisselogimisteavet (nimi, e-post, profiil), ütleb Google, et rakenduse kinnitamine ei ole kohustuslik. Kasutajate Gmaili, Drive'i või Kalendri juurdepääsu küsimine on teine asi ja nõuab kinnitamist.

Ehita ise või kasuta pakkujat?

Kõik kaks esimest on mõistlikud. Hostitud pakkujad teevad rohkem sinu eest, kuid lisavad sõltuvuse ja mõnikord maksavad aktiivse kasutaja kohta; hinnad kontrolli nende lehtedelt. Teegid hoiavad kõik sinu andmebaasis, kuid jätavad rohkem sinu seadistada õigesti. Mida ka valid, palu AI-l kasutada seda, mitte kirjutada parooli- ega sessioonilogikat käsitsi.

Rollid ja õigused

Sisselogimine ütleb, kes keegi on. Õigused otsustavad, mida ta teha tohib. Alguses hoia lihtne:

Reeglid, mis on olulisemad kui rollinimed:

• Kontrolli serveris, iga kord. Nupu peitmine lehel ei takista kedagi API-d otse kutsumast.
• Piira omaniku järgi. Liige, kes pärib „broneering 123“, peaks selle saama ainult siis, kui see on tema oma.
• Kasutajad ei saa ise end ülendada. Ignoreeri profiiliuuendustes brauserist saadetud rollivälju.
• Vaikimisi ligipääs puudub. Uued teed peaksid nõudma sisselogimist, välja arvatud juhul, kui otsustad teisiti.

Testi kahe kontoga: logi sisse ühe kasutajana, märgi kirje ID üles, logi sisse teise kasutajana ja proovi seda avada. Meie turvakontrollnimekiri AI-ga ehitatud rakendustele sisaldab täielikku testi.

Sessiooni turvalisus

Pärast sisselogimist mäletab rakendus kasutajat sessiooni abil — tavaliselt küpsise abil. OWASP-i sessioonihalduse juhend soovitab:

• Sessiooniküpsised seatud atribuutidega Secure (ainult HTTPS), HttpOnly (lehe skriptid ei saa lugeda) ja SameSite
• Uus sessiooni ID väljastatakse sisselogimisel ja uuesti, kui õigused muutuvad
• Tegevusetuse ajalõpp ja absoluutne maksimaalne eluiga, mida jõustab server
• Väljalogimine lõpetab sessiooni serveris, mitte ainult ei kustuta küpsist
• Sessioonid tühistatakse, kui kasutaja muudab oma parooli

Sisselogimistokenite hoidmine brauseri localStorage'is on õpetustes tavaline, kuid see avab need igale lehel töötavale skriptile; turvalised küpsised on veebirakenduste jaoks tavaliselt parem vaikevalik.

Prompt, mis katab olulise

Lisa sellele rakendusele kasutajakontod. Kasutajad saavad registreeruda ja sisse logida e-posti ja parooliga või Google'iga. Kasuta autentimiseks [teek või teenus] kohandatud autentimiskoodi asemel. Räsi paroolid Argon2id või bcrypt-iga. Lisa parooli lähtestamine e-posti teel ühekordse lingiga, mis aegub tunni pärast. Hoia sessioone turvalistes HttpOnly küpsistes. Kaitse /dashboard ja iga /api teekonda nii, et ainult sisselogitud kasutajad saavad neid kasutada, ning veendu, et kasutajad näevad ainult oma projekte. Lisa roll „admin“, mis näeb kõiki kasutajaid; ainult administraatorid pääsevad /admin lehele, mida kontrollitakse serveris.

Seejärel testi: registreeru, logi välja, logi sisse, lähtesta parool, proovi privaatset URL-i väljalogituna ja proovi teise kasutaja kirjet.

Levinud vead AI-ga ehitatud sisselogimises

• Kaitse ainult lehel. Leht suunab väljalogitud kasutajad ümber, kuid API tagastab andmed igaühele.
• Saladused brauseris. OAuth-kliendi saladused ja autentimisteenuse administraatorivõtmed kuuluvad serverisse.
• Eelvaate ja avaliku URL-i segiajamine. Google'i suunamis-URI või parooli lähtestamise e-kirja link osutab eelvaatele, seega sisselogimine katkeb pärast avaldamist.
• E-posti kinnituse puudumine. Igaüks saab registreeruda kui anyone@company.com. Kinnita e-post enne, kui annad selle aadressiga seotud õigusi.
• Testimine ainult õnnelikul teel. Proovi valesid paroole, aegunud linke ja teist kontot.

Sisselogimise lisamine Mythexis

Mythexis on sisselogimine sinu rakenduse kasutajatele midagi, mille lisad oma rakendusse — see on eraldi sinu Mythexi kontost. Mythex ei paku sisseehitatud autentimistoodet, seega toote sa autentimisteegi või pakkuja ja tema võtmed:

1. Vali lähenemine — näiteks e-post ja parool, mida hoitakse sinu andmebaasis, või hostitud pakkuja SDK.
2. Kui hoiad kasutajaid ise, vajab rakendus andmebaasi; küsi seda vestluses või kasuta /database.
3. Pane pakkuja võtmed projekti saladustesse (/secrets või projekti seaded).
4. Kasuta ülaltoodud stiilis prompti ja testi eelvaates. Google'i sisselogimise jaoks lisa suunamis-URI-d nii oma eelvaate kui ka avaldatud aadressi jaoks.

Vt dokumentatsioonist sisselogimise lisamine rakendusse. Kui ehitad tasulist toodet, käsitleb kuidas ehitada SaaS MVP kontosid ja arveldust koos.

Küsimused