WordPressin autentikointi näyttää ulospäin yksinkertaiselta: käyttäjä kirjautuu sisään, selaa hallintapaneelia ja tekee asioita oikeuksiensa puitteissa. Kulissien takana WordPress ei kuitenkaan käytä perinteistä sessiopohjaista mallia samalla tavalla kuin monet muut web-sovellukset. Sen sijaan se nojaa vahvasti evästeisiin, kryptografisiin allekirjoituksiin ja aikarajoitettuihin tokeneihin.
Tämä arkkitehtuuri on historiallinen kompromissi, mutta samalla yllättävän moderni ja skaalautuva. Ymmärtämällä, miten WordPress käsittelee autentikointia ja “sessioita”, kehittäjä pystyy rakentamaan turvallisempia lisäosia, luotettavampia REST API -ratkaisuja ja välttämään yleisiä tietoturvavirheitä.
Tässä artikkelissa pureudutaan syvällisesti WordPressin autentikointimalliin, evästeisiin, nonceihin, sessiokäsitteeseen ja siihen, miksi WordPress ei oikeastaan käytä sessioita lainkaan perinteisessä merkityksessä.
WordPress ei käytä PHP-sessioita
Ensimmäinen ja usein yllättävin fakta on tämä: WordPress ei oletuksena käytä PHP:n $_SESSION-mekanismia.
Ei sessiotiedostoja, ei sessio-ID:tä palvelimella, ei server-side session storea. Tämä ei ole vahinko, vaan tietoinen suunnittelupäätös, joka juontaa juurensa WordPressin varhaisista versioista.
Tämä tekee WordPressistä:
– helpommin skaalautuvan
– vähemmän riippuvaisen palvelinympäristöstä
– paremmin yhteensopivan välimuistien kanssa
WordPressin “sessio” on käytännössä kryptografisesti allekirjoitettu eväste.
Autentikointi vs. istunto WordPressissä
WordPress erottaa kaksi asiaa, vaikka ne usein sekoitetaan:
– autentikointi: kuka käyttäjä on
– istunto: onko käyttäjä edelleen “kirjautuneena”
Autentikointi tapahtuu kirjautumishetkellä. Istunnon ylläpito tapahtuu evästeiden avulla ilman palvelinpuolen tilaa.
WordPress ei muista käyttäjää muistissa. Se tarkistaa käyttäjän jokaisella pyynnöllä uudelleen.
Kirjautumisprosessi vaihe vaiheelta
Kun käyttäjä syöttää käyttäjätunnuksen ja salasanan kirjautumissivulla, WordPress:
– hakee käyttäjän tietokannasta
– vertaa salasanan hashia
– luo autentikointievästeet
Tässä vaiheessa WordPress ei luo sessiota palvelimelle. Sen sijaan se asettaa selaimeen useita evästeitä, jotka toimivat todisteena kirjautumisesta.
WordPressin autentikointievästeet
WordPress käyttää useita evästeitä eri tarkoituksiin. Keskeisimmät ovat:
– auth cookie
– secure auth cookie
– logged-in cookie
Näiden sisältö ei ole pelkkä käyttäjätunnus. Evästeeseen tallennetaan:
– käyttäjän ID
– käyttäjänimi
– aikaleima
– HMAC-allekirjoitus
Allekirjoitus tehdään wp-config.php:ssa määritellyillä avaimilla ja salteilla.
Kryptografia evästeissä
WordPressin evästeet ovat kryptografisesti suojattuja. Käyttäjä ei voi muokata evästettä ilman, että allekirjoitus rikkoutuu.
Kun WordPress vastaanottaa pyynnön, se:
– lukee evästeen
– laskee allekirjoituksen uudelleen
– vertaa sitä evästeessä olevaan arvoon
Jos allekirjoitus täsmää ja aikaraja ei ole ylittynyt, käyttäjä katsotaan autentikoiduksi.
Tämä tapahtuu jokaisella pyynnöllä.
Aikarajat ja “sessioiden” kesto
WordPressin autentikointievästeet ovat aikarajoitettuja. Tämä on WordPressin vastine sessioille.
Evästeessä oleva aikaleima määrittää, kuinka kauan kirjautuminen on voimassa. Kun aika ylittyy, eväste hylätään automaattisesti.
“Kyllä muista minut” -valinta vaikuttaa vain evästeen voimassaoloaikaan, ei autentikointimalliin.
Kirjautuminen ei ole tila, vaan todiste
WordPress ei säilytä tietoa “aktiivisista sessioista” keskitetysti. Jokainen pyyntö todistaa itse olevansa laillinen.
Tämä tekee järjestelmästä:
– stateless
– hyvin välimuistikelpoisen
– helposti skaalautuvan
Haittapuolena on se, että WordPress ei voi helposti “potkaista ulos” yksittäistä sessiota ilman lisämekanismeja.
Salttien ja avainten rooli
wp-config.php:ssa määritellyt AUTH_KEY, LOGGED_IN_KEY ja muut avaimet ovat kriittisiä autentikoinnille.
Jos nämä avaimet vaihtuvat:
– kaikki evästeet muuttuvat kelvottomiksi
– kaikki käyttäjät kirjautuvat ulos
Tämä on karkea mutta tehokas keino katkaista kaikki kirjautumiset esimerkiksi tietoturvahyökkäyksen jälkeen.
Noncet ja sessioturvallisuus
Nonce ei ole sessio eikä salasana. Se on aikarajoitettu todiste siitä, että pyyntö on peräisin autentikoidulta käyttäjältä.
WordPressin noncet:
– sidotaan käyttäjään
– sidotaan aikaan
– sidotaan toimintaan
Ne estävät CSRF-hyökkäyksiä, eivät kirjautumista.
Nonce toimii vain, jos käyttäjä on jo autentikoitu evästeiden avulla.
current_user ja autentikointiketju
Kun WordPress käynnistyy, se yrittää tunnistaa käyttäjän hyvin varhaisessa vaiheessa bootstrap-prosessia.
Se:
– lukee evästeet
– validoi ne
– lataa käyttäjäobjektin
Tämän jälkeen current_user on käytettävissä koko pyynnön ajan.
Tämä tapahtuu jokaisella pyynnöllä uudelleen.
REST API ja autentikointi
REST API käyttää samaa autentikointimallia kuin perinteinen WordPress. Jos pyyntö sisältää kelvolliset evästeet, käyttäjä on kirjautunut.
Selainpohjaisessa käytössä tämä toimii automaattisesti. Ulkoisissa sovelluksissa tarvitaan muita malleja, kuten Application Passwords tai OAuth.
REST API ei luo omia sessioita.
Application Passwords ja sessiottomuus
Application Passwords toimivat samalla periaatteella kuin evästeet, mutta HTTP-headerin kautta.
Ne:
– tunnistavat käyttäjän
– eivät luo sessiota
– ovat aina stateless
Tämä tekee niistä turvallisia ja ennustettavia palvelinten välisessä kommunikoinnissa.
Miksi PHP-sessiot ovat ongelmallisia WordPressissä
PHP-sessiot vaatisivat:
– yhteisen session store -ratkaisun
– lukituksia
– lisäkonfiguraatiota
Ne vaikeuttaisivat välimuistia ja horisontaalista skaalausta.
WordPressin evästepohjainen malli välttää nämä ongelmat kokonaan.
Lisäosat ja väärät sessiot
Yksi yleisimmistä WordPressin arkkitehtuurivirheistä on lisäosa, joka ottaa käyttöön PHP-sessiot omiin tarpeisiinsa.
Tämä voi:
– rikkoa sivuvälimuistin
– aiheuttaa satunnaisia kirjautumisongelmia
– estää skaalautuvuuden
Jos WordPressissä tarvitaan tilaa käyttäjän ja pyynnön välille, siihen on parempia ratkaisuja kuin $_SESSION.
WooCommerce ja “sessioiden” illuusio
WooCommerce käyttää omaa session-kerrosta, mutta sekin on rakennettu WordPressin stateless-mallin päälle.
WooCommerce-session data tallennetaan tietokantaan tai välimuistiin, ei PHP-sessioon. Eväste toimii vain avaimena tähän dataan.
Tämä on tärkeä ero perinteiseen sessiomalliin.
Kirjautumisen mitätöinti
WordPress ei voi mitätöidä yksittäistä evästettä suoraan. Se voi:
– vaihtaa avaimet
– mitätöidä kaikki kirjautumiset
– pakottaa salasanan vaihdon
Lisäosilla voidaan rakentaa hienojakoisempia ratkaisuja, mutta ne eivät ole osa corea.
Tietoturva ja sessiomalli
WordPressin autentikointimalli on turvallinen, kun sitä käytetään oikein. Suurimmat riskit eivät liity itse malliin, vaan:
– heikkoihin salasanoihin
– varastettuihin evästeisiin
– XSS-haavoittuvuuksiin
Evästeet ovat vain niin turvallisia kuin ympäristö, jossa niitä käytetään.
HTTPS on pakollinen
Ilman HTTPS:ää WordPressin autentikointievästeet ovat käytännössä turvattomia.
Secure-cookie-asetukset, HSTS ja oikein konfiguroitu palvelin ovat edellytys turvalliselle autentikoinnille.
Autentikointimalli ei voi kompensoida huonoa infrastruktuuria.
Autentikointi osana arkkitehtuuria
WordPressin autentikointi ei ole irrallinen ominaisuus. Se vaikuttaa:
– välimuistiin
– skaalautuvuuteen
– REST API -suunnitteluun
– tietoturvaan
Kun tämä ymmärretään, WordPressiä ei yritetä pakottaa toimimaan kuin perinteinen sessiopohjainen sovellus.
Lopuksi
WordPress ei käsittele autentikointia ja sessioita kuten monet muut järjestelmät, eikä sen tarvitsekaan. Sen evästepohjainen, stateless-malli on yksinkertainen, tehokas ja yllättävän moderni.
Ymmärtämällä tämän mallin kehittäjä välttää turhia virityksiä, rakentaa turvallisempia ratkaisuja ja osaa hyödyntää WordPressiä sellaisena kuin se on tarkoitettu käytettäväksi.
WordPressissä sessio ei ole tila. Se on todiste. Ja se todiste tarkistetaan joka kerta uudelleen.
