Vodnik za WordPress REST API avtentikacijo

Uvod v WordPress REST API avtentikacijo

WordPress API vmesnik REST API je močno orodje, ki omogoča dostop do WordPress vsebine in funkcionalnosti prek HTTP zahtev iz katere koli aplikacije, bodisi mobilne aplikacije, JavaScript frontenda, zunanje storitve ali popolnoma ločene spletne aplikacije. Vendar pa branje javne vsebine običajno ne zahteva avtentikacije, ustvarjanje, posodabljanje in brisanje vsebine pa zahteva, da se uporabnik avtenticira, da WordPress ve, kdo izvaja akcijo in ali ima potrebna dovoljenja.

WordPress podpira več metod avtentikacije za REST API, vsaka pa ima svoje prednosti, slabosti in idealne scenarije uporabe. Izbira prave metode je odvisna od tega, kdo dostopa do API (frontend na istem spletni strani, zunanja aplikacija, mobilna aplikacija), kakšna raven varnosti je potrebna in kako kompleksno integracijo želite implementirati. V tem vodniku gremo podrobno skozi vsako metodo s praktičnimi primeri.

Cookie avtentikacija z nonce

Cookie avtentikacija je privzeta metoda za zahteve, ki prihajajo s samega WordPress spletne strani, običajno iz JavaScript kode v skrbniški plošči ali na frontendu. Ko je uporabnik prijavljen v WordPress, brskalnik z vsako zahtevo samodejno pošlje cookie in WordPress REST API ga uporablja za identifikacijo uporabnika. Vendar pa sam cookie ni dovolj, saj bi to omogočilo CSRF napade, kjer lahko zlonamerna spletna stran sproži zahteve v imenu prijavljenega uporabnika.

Kako deluje nonce

WordPress uporablja nonce (number used once) kot dodaten sloj zaščite pred CSRF napadi. Nonce je časovno omejen žeton, ki ga WordPress generira za prijavljenega uporabnika in ki ga je treba poslati ob vsaki mutating zahtevi (POST, PUT, DELETE). JavaScript koda ga pridobi prek funkcije wp_localize_script() ali globalne spremenljivke wpApiSettings.nonce v skrbniški plošči.

• Generiranje - wp_create_nonce('wp_rest') na strani strežnika
• Posredovanje - wp_localize_script() za posredovanje nonce v JavaScript
• Pošiljanje - X-WP-Nonce header ali _wpnonce query parameter
• Veljavnost - nonce poteče po 24 urah (dve WordPress nonce periodi po 12h)
• Revalidacija - za dolgotrajne seje periodično zahtevajte nov nonce prek API

Cookie avtentikacija je idealna za JavaScript kodo, ki se izvaja na sami WordPress spletni strani, saj ne zahteva nikakršne dodatne konfiguracije, razen pravilnega posredovanja nonce. Ni primerna za zunanje aplikacije, saj te ne morejo dostopati do WordPress cookieja. Prav tako upoštevajte, da nonce poteče in da dolgotrajne seje zahtevajo mehanizem za osvežitev žetona, da uporabnik ne bo dobil napake 403 sredi dela.

Application Passwords

Application Passwords so bili uvedeni v WordPress 5.6 kot vgrajena metoda za avtentikacijo zunanjih aplikacij brez podajanja glavnega gesla uporabnika. Vsak uporabnik lahko ustvari več application passwordov z opisnimi imeni (npr. Mobile App, Zapier Integration, Custom Script) in vsako je mogoče neodvisno preklicati brez vpliva na ostale ali na glavno geslo uporabnika.

Ustvarjanje in uporaba

Application password se ustvari v WordPress skrbniški plošči pod Users, Edit User, sekcija Application Passwords. Vnesete ime aplikacije in WordPress generira geslo iz 24 znakov, združenih v 4 skupine po 6 znakov, ločenih s presledki. To geslo se uporablja za HTTP Basic Authentication, kjer se uporabniško ime in application password v Authorization headerju pošljeta kodirana v base64 formatu.

Zahteva z Application Password izgleda kot standardni HTTP Basic Auth: Authorization header vsebuje Basic, ki mu sledi base64 kodiran niz username:application_password. Presledki v geslu se ignorirajo, zato jih lahko odstranite ali pustite. WordPress samodejno prepozna, da gre za Application Password in ne za glavno geslo uporabnika, ter uporabi ustrezna dovoljenja.

Prednosti in omejitve

• Preprostost - vgrajena funkcionalnost brez potrebe po vtičnikih
• Granuliran nadzor - vsaka aplikacija ima lastno geslo, ki ga je mogoče preklicati
• Logging - WordPress beleži zadnjo uporabo vsakega application gesla
• Omejitev - deluje samo prek HTTPS, saj Basic Auth pošilja kredenciale ob vsaki zahtevi
• Omejitev - nima scope ali permission granularnosti zunaj uporabniške vloge

Application Passwords so odlična izbira za server-to-server integracije, idealno za VPS hosting okolja, avtomatizacijske skripte in aplikacije, kjer je preprostost pomembnejša od granuliranega nadzora dostopa. Obvezno uporabljajte HTTPS, saj se kredenciali pošiljajo ob vsaki zahtevi in jih je brez HTTPS mogoče prestreči. Za produkcijske integracije ustvarite ločenega WordPress uporabnika z minimalno potrebnimi dovoljenji namesto uporabe admin računa.

OAuth 2.0

OAuth 2.0 je industrijski standard za avtorizacijo, ki ga uporabljajo Google, Facebook, GitHub in številne druge storitve. WordPress nima vgrajene OAuth podpore, vendar je na voljo prek vtičnikov, kot sta WP OAuth Server in OAuth 2.0 Provider. OAuth je idealen za scenarije, kjer želite third-party aplikacijam omogočiti dostop do vašega WordPress API z natančnim nadzorom nad dovoljenji brez deljenja uporabniških kredencialov.

OAuth 2.0 flow

Najpogostejši OAuth flow za spletne aplikacije je Authorization Code flow, ki je sestavljen iz več korakov. Aplikacija preusmeri uporabnika na WordPress authorize endpoint, kjer uporabnik odobri dostop. WordPress uporabnika preusmeri nazaj na aplikacijo z authorization code. Aplikacija zamenja code za access token s klicem na token endpoint. Access token se nato uporablja za API zahteve v Authorization Bearer headerju.

• Authorization Code - najvarnejši flow za spletne aplikacije s strežniško stranjo
• Implicit - za SPA aplikacije brez strežnika (manj varen, običajno ni priporočen)
• Client Credentials - za server-to-server komunikacijo brez uporabniškega konteksta
• PKCE - Proof Key for Code Exchange, izboljša varnost za mobilne in SPA aplikacije

OAuth zagotavlja najvišjo raven nadzora in varnosti, vendar je tudi najkompleksnejši za implementacijo. Access tokeni imajo omejen rok trajanja in uporabljajo se refresh tokeni za pridobivanje novih brez ponovne avtorizacije uporabnika. Parameter scope določa, katera dovoljenja aplikacija zahteva, kar uporabniku daje transparentnost o tem, kaj aplikacija lahko počne z njegovimi podatki.

JWT (JSON Web Tokens)

JWT avtentikacija je priljubljena alternativa za REST API dostop, ki uporablja žetone namesto sej. JWT žeton je podpisan niz, ki vsebuje informacije o uporabniku in dovoljenjih in se pošilja v Authorization headerju vsake zahteve. WordPress nima vgrajene JWT podpore, vendar je na voljo prek vtičnikov, kot sta JWT Authentication for WP REST API in Simple JWT Login.

Kako deluje JWT

Uporabnik pošlje uporabniško ime in geslo na token endpoint (običajno /wp-json/jwt-auth/v1/token) in v odgovoru dobi JWT žeton. Ta žeton se nato pošilja v Authorization: Bearer headerju vseh API zahtev. Strežnik preveri podpis žetona in izvleče informacije o uporabniku brez potrebe po iskanju v podatkovni bazi, kar JWT naredi učinkovitejši za API z visoko obremenitvijo.

JWT žeton je sestavljen iz treh delov, ločenih s pikami: header (algoritem in vrsta žetona), payload (podatki o uporabniku, čas izteka, izdajatelj) in signature (kriptografski podpis, ki zagotavlja integriteto žetona). Žeton je mogoče dekodirati na strani odjemalca, vendar ga ni mogoče ponarediti brez secret key, ki ga pozna samo strežnik. To odjemalcu omogoča, da prebere informacije o uporabniku iz žetona brez dodatnega API klica.

Prednosti JWT

• Stateless - strežnik ne hrani sej, kar olajša skaliranje
• Self-contained - žeton vsebuje vse potrebne informacije o uporabniku
• Cross-domain - deluje z različnimi domenami brez CORS težav s cookieji
• Mobilne aplikacije - idealen za mobilne aplikacije, ki ne uporabljajo cookiejev
• Zmogljivost - preverjanje žetona ne zahteva poizvedbe v podatkovno bazo

Primerjava metod avtentikacije

Izbira metode avtentikacije je odvisna od vašega specifičnega scenarija. Cookie in nonce sta idealna za JavaScript na istem spletni strani, saj ne zahtevata dodatne konfiguracije. Oglejte si naše hosting pakete za WordPress spletne strani za optimalno okolje. Application Passwords so najboljši za preproste server-to-server integracije in skripte, saj so vgrajeni in enostavni za uporabo. OAuth 2.0 je prava izbira za third-party aplikacije, kjer je potreben granuliran nadzor dostopa in uporabniška avtorizacija. JWT je optimalen za mobilne aplikacije in SPA ogrodja, ki komunicirajo z WordPress kot headless CMS.

Varnostna priporočila

• Vedno uporabljajte HTTPS - vse metode avtentikacije zahtevajo šifrirano povezavo
• Minimalna dovoljenja - ustvarjajte uporabnike samo s potrebnimi dovoljenji za API dostop
• Token rotation - implementirajte refresh tokene in kratke roke access tokenov
• Rate limiting - omejite število zahtev na uporabnika za zaščito pred brute-force napadi
• Logging - beležite vse API zahteve za revizijo in odkrivanje zlonamernih aktivnosti
• CORS konfiguracija - omejite dostop do API samo z dovoljenih domen

Za produkcijske aplikacije priporočamo kombinacijo več metod, kjer vsaka pokriva drug scenarij. Cookie avtentikacija za admin ploščo in frontend interakcije, Application Passwords za interne skripte in avtomatizacijo, JWT za mobilne aplikacije in OAuth za third-party integracije. Redno pregledujte aktivne žetone in application passwords ter prekličite tiste, ki se ne uporabljajo več, saj je vsak aktiven žeton potencialen vektor napada.