Mikä on todennus? Kirjautumiset, istunnot ja OAuth selitettynä

Todennus on tapa, jolla sovellus varmistaa, kuka käyttäjä on – yleensä tarkistamalla jotakin, minkä käyttäjä tietää (salasana), jotakin, mitä hänellä on (koodi puhelimeen tai sähköpostiin), tai identiteetin toisesta luotetusta palvelusta (kuten ”Kirjaudu Googlella”). Kun käyttäjä on todennettu, sovellus muistaa hänet istunnolla tai tokenilla, jotta hänen ei tarvitse kirjautua joka sivulla uudelleen. Sen päättäminen, mitä tunnettu käyttäjä saa tehdä, on erillinen vaihe, jota kutsutaan valtuutukseksi.

Miksi tämä on tärkeää, kun rakennat tekoälyllä

Kirjautumisen lisääminen on yksi yleisimmistä pyynnöistä tekoälyrakentajalle, ja yksi helpoimmista asioista tehdä hienovaraisesti väärin. Kirjautumissivu on helppo generoida. Vaikea osa on kaikki sen ympärillä:

• Tallennetaanko salasanat turvallisesti?
• Tarkistaako jokainen yksityinen sivu ja jokainen API-päätepiste todella, kuka pyytää?
• Voiko kirjautunut asiakas nähdä toisen asiakkaan datan vaihtamalla URL:n numeroa?
• Mitä tapahtuu, kun joku unohtaa salasanansa?

Sovellus voi näyttää täysin turvalliselta ja silti epäonnistua kaikissa näissä. Liikkuvien osien ymmärtäminen auttaa sinua kysymään oikeita kysymyksiä ja testaamaan oikeita asioita.

Arkinen vertauskuva

Ajattele hotelliin sisäänkirjautumista.

Vastaanotossa näytät henkilöllisyystodistuksen. Se on todennusta: todistat, kuka olet. Vastaanottaja antaa sitten avainkortin. Kortti on istuntosi: loppuajan et näytä henkilöllisyystodistusta uudelleen, vaan napautat korttia.

Kortti avaa huoneesi, kuntosalin ja hissin kerrokseesi – mutta ei muiden vieraiden huoneita tai henkilökunnan toimistoa. Se on valtuutusta: mihin identiteettisi pääsee käsiksi. Jos kortti katoaa, hotelli voi deaktivoida sen vastaanotossa (istunnon peruutus). Kun uloskirjaudut, se lakkaa toimimasta (uloskirjautuminen tai vanheneminen).

”Kirjaudu Googlella” on kuin hotelli, joka hyväksyy luotetulta kumppanilta tulleen kirjeen, jossa lukee ”tämä on henkilö X”, sen sijaan että tarkistaisi henkilöllisyytesi itse.

Pääasialliset kirjautumistavat

Miten salasanat pitäisi tallentaa

Turvallinen sovellus ei koskaan tallenna varsinaista salasanaasi. Sen sijaan se tallentaa tiivisteen: yksisuuntaisen funktion tuloksen, joka muuttaa salasanan kiinteän mittaiseksi merkkijonoksi. Kun kirjaudut sisään, sovellus tiivistää kirjoittamasi ja vertaa tulosta tallennettuun tiivisteeseen.

Kaksi yksityiskohtaa tekevät tästä turvallista:

• Suola – satunnainen arvo, joka lisätään jokaiseen salasanaan ennen tiivistämistä, joten kahdella ihmisellä samalla salasanalla on eri tiivisteet, eivätkä valmiiksi lasketut hakutaulukot toimi.
• Hidas, salasanoihin tarkoitettu algoritmi – kuten Argon2, bcrypt tai scrypt. Yleiskäyttöiset tiivisteet, kuten MD5 tai SHA-256, ovat liian nopeita yksinään; hyökkääjät voivat kokeilla miljardeja arvauksia.

Tiivistäminen ei ole sama asia kuin salaus. Salattu data voidaan purkaa avaimella; salasanatiiviste on suunniteltu siten, ettei sitä voi kääntää takaisin lainkaan.

Istunnot vs tokenit

Kirjautumisen jälkeen sovelluksen on tunnistettava sinut jokaisessa pyynnössä. Yleisiä lähestymistapoja on kaksi.

Evästeiden kohdalla kolme asetusta on tärkeitä: HttpOnly (sivun JavaScript ei voi lukea evästettä), Secure (lähetetään vain HTTPS:n yli) ja SameSite (rajoittaa lähettämistä muilta sivustoilta tulevissa pyynnöissä). Tokenien tallentaminen selaimen localStorageen on yleistä, mutta se altistaa ne jokaiselle sivulla ajettavalle skriptille.

OAuth ja ”Kirjaudu Googlella”

OAuth 2.0 on standardi delegoidulle valtuutukselle: sen avulla sovellus saa rajoitetun pääsyn tiliisi toisessa palvelussa – esimerkiksi lukea Google-kalenteriasi – koskaan näkemättä Google-salasanaasi. Sinut ohjataan Googleen, hyväksyt tietyt oikeudet (joita kutsutaan scopeiksi), ja Google antaa sovellukselle tokenin vain näille oikeuksille.

OAuth itsessään suunniteltiin myöntämään pääsy, ei kertomaan, kuka olet. OpenID Connect (OIDC) on OAuth 2.0:n päällä oleva kerros, joka lisää identiteetin – sitä ”Kirjaudu Googlella” tai ”Kirjaudu Applella” käyttää. Asetuksessa rekisteröit sovelluksesi palveluntarjoajalle ja saat client ID:n ja client secretin; salaisuus pysyy palvelimellasi.

Esimerkki käytännössä: kirjautuminen asiakasportaaliin

Oletetaan, että rakennat portaalia, jossa suunnittelutoimiston asiakkaat näkevät projektinsa ja laskunsa.

• Todennus: asiakkaat kirjautuvat sähköpostilla ja taikalinkillä, joten salasanoja ei tarvitse hallita. Toimiston henkilökunta kirjautuu Google Workspace -tileillä.
• Roolit: jokaisella käyttäjällä on rooli – client tai staff.
• Valtuutussäännöt:

• Missä se pakotetaan: palvelimella, jokaisessa pyynnössä. Palvelin etsii kirjautuneen käyttäjän ja palauttaa vain projektit, joissa project.company_id vastaa käyttäjän yritystä. Pelkkä ”Merkitse maksetuksi” -painikkeen piilottaminen ei riitä – päätepisteen itsensä on kieltäydyttävä.

Yleisten termien selitykset

Yleisiä virheitä ja väärinkäsityksiä

• Oikeuksien tarkistaminen vain sivulla. Jos selain piilottaa painikkeen, mutta API ei tarkista, kuka tahansa voi kutsua API:a suoraan.
• URL:n tunnusten luottaminen. /invoices/1042 on tarkistettava, että lasku 1042 kuuluu kirjautuneelle käyttäjälle.
• Oman salauksen kehittäminen. Käytä tunnettuja kirjastoja tai palveluntarjoajia; älä anna tekoälyn keksiä tiivistysmenetelmää.
• Heikko salasanan nollaus. Nollauslinkkien tulee olla kertakäyttöisiä, vanheta nopeasti eivätkä paljasta, onko sähköpostilla tiliä.
• Oman kirjautumisen sekoittaminen rakentajatyökalun kirjautumiseen. Sovelluksesi käyttäjät ovat erillään tilistäsi työkalulla, jolla rakennat.
• Ei nopeusrajoitusta kirjautumiselle. Ilman sitä hyökkääjät voivat kokeilla salasanoja loputtomiin.

Mitä pyytää tekoälyrakentajaltasi

• ”Lisää rekisteröityminen ja kirjautuminen käyttäen [tunnettua kirjastoa tai palveluntarjoajaa]. Älä kirjoita omaa salasanatiivisteen toteutusta.”
• ”Tallenna salasanat bcryptillä tai Argon2:lla tiivistettyinä.”
• ”Käytä HttpOnly- ja Secure-evästeitä istunnolle.”
• ”Lisää roolit: admin ja member. Listaa jokainen päätepiste ja mitkä roolit saavat kutsua sitä.”
• ”Pakota palvelimella, että käyttäjät voivat lukea ja muokata vain omia tietueitaan. Näytä sitten, miten tarkistit sen.”
• ”Lisää salasanan nollaus kertakäyttöisillä linkeillä, jotka vanhenevat tunnissa.”
• ”Rajoita kirjautumisyritysten määrää.”

Testaa sitten itse: luo kaksi tiliä ja yritä päästä toisen tietoihin kirjautuneena toisena. Opas kirjautumisen lisäämiseen ja tietoturvatarkistuslista menevät pidemmälle.

Todennus Mythexissä

Mythex ei tarjoa sisäänrakennettua todennustuotetta sovelluksesi käyttäjille; valitset lähestymistavan – sähköposti ja salasana tallennettuna projektisi tietokantaan tai hallitun palveluntarjoajan SDK – ja pyydät agenttia lisäämään sen. Palveluntarjoajien avaimet menevät projektin salaisuuksiin, ei chattiin. Tämä on erillinen asia siitä, miten kirjaudut sisään itse Mythexiin. Dokumentaation resepti kirjautumisen lisäämisestä sovellukseen sisältää aloituskehotteen, jota voit muokata, ja mikä on API selittää, missä nuo palvelinpuolen tarkistukset sijaitsevat.

Kysymykset