PHP | komunikace web -> API -> web jen skrze token

Ahoj, mam v PHP napsany web, kde jsem si udelal mechanismus, ktery povazuji za zlepsene zabezpeceni a chtel jsem to otestovat v praxi. Web je totiz napojeny na API (tez PHP/MySQL) a nechci, aby do nej mohl kdokoli, kdo bude bystrejsi v IT. Postup je tento: 1/ jakmile nekdo prijde na web web, kontroluje se existenci urcite session, ktera drzi token. Pokud session neexistuje, zavola se API, ktere token vrati a ulozi do session. 2/ na kazde dalsi strance se uz token nezaklada, ale web pri dotazu posila do API prave tento pozadavek jako potvrzeni, ze jde pozadavek opravdu z webu a ne treba z jineho zdroje 3/ kdyz session vyprsi, tak se pri refreshy stranky opet vygeneruje novy token a postup je stejny Udelal jsem to takto proto, ze pokud byl mezi webem a API jeden staly token a na webu formular, ktery chci poslat do API pomoci jQuery se zarukou overeni tokenu (tzn. formular neni odeslany primo do API requestem odkudkoli, ale opravdu ho tam posila web), tak bych musel tento komunikacni token nekde v HTML kodu vypsat a byl by viditelny pro vsechny. Coz v pripade, ze je token dynamicky generovany v podstate pro kazdou navstevu webu nehrozi. Sice ho vlastne vidi vsichni, ale kazdy jen ten svuj. Mam ale tuseni, ze mohou byt zarizeni/platformy, ktera s tim maji problem. Obcas neco sdilim na FB se zpetnym linkem a dela to na me dojem, ze ten FB robot treba session neumi a posle mi treba 5 pozadavku na overeni za sebou behem sekundy. V API mam log pozadavku na ruzne URL. Zatim k nim tedy neukladam udaj typu "user_agent" a urcite to udelam. Ale zajima me, zda je tohle realne pouzivane? Prijde mi, ze to neni nic hrozneho. Ve chvili, kdy pracuji treba s platebni branou, tak se taky u nekterych poskytovatelu (GoPay) nejdriv platba zalozi, vrati se vam token a na zaklade toho se komunikuje. A presne proto, aby tam byla zaruka, ze to je pozadavek z webu. Muze se stat neco takoveho, pripadne jak se toto resi, kdyz chci, aby token zustal skryty? Moc diky za rady zdejsich expertu :)

Používání tokenů určitě není nic nového, doporučil bych se podívat jak funguje třeba oAuth, třeba i ve spojení s JWT, to jsou relativně rozšířené a používané standardy.

jdeš na to dobře, ale vhodnější je použít existující řešení a držet se obvyklých postupů.Ten token a přihlašování je sezení. Použij klasické php session a jeho cookies, v $_SESSION na straně serveru si pak můžeš pamatovat stav a případně vyvolat redirect přes http hlavičky. JS do session cookies nemá přístup (je http only) a nemůže jí tedy ani poslat pryč. Prohlížeč to přikládá k požadavku automaticky.Ta další část ochrany co chceš dělat je CSRF (vyhledej si). Pro každý požadavek z api na uložení dat si nejprve ze serveru vyžádáš token, ten si na straně serveru uložíš do $_SESSION s nějakou časovou platností. Token můžeš automaticky generovat s odpovědí z api, ať ušetříš jeden požadavek. Při generování tokenu pak jen nezapomeň vždy všechny projít, smazat expirované a smazat nejstarší pokud jich je třeba více než 100. Při api požadavku samozřejmě nejprve ověříš token, pokud neprojde, vrátíš infornaci frontendu, ten si vyžádá nový token a zkusí to znovu. Frontend by měl po cca 2 neúspěšných pokusech zobrazit chybu návštěvníkovi, ať to neděláš do nekonečna.JWT je užitečná věc, nemusíš si tokeny na serveru pamatovat, jsou jen na klientu volitelně zašifrované a digitálně podepsané, jinak to funguje obdobně, jako jsem popsal výše.

Asi by bylo dobré si rozhodnou pro které stránky vlastně ten rokem je nutný a pro některé není a ty mají být tedy lehce dostupné i pro FB čili veřejné

Mechanismus, který ty a TomášX popisujete, se také nazývá "challenge-response" (výzva-odpověď), kde "výzva" je právě to pro ostatní neznámé heslo/kód, třeba v podobě náhodného řetězce v session, který přidáváš jako kontrolu do požadavků na web/do API. Případ neshody se považuje za CSRF. Použití je na zabezpečené oblasti stránek, pro odesílání formulářů nebo všude tam, kde chceš, aby požadavky na tvé stránky/API byly volány jen určitým způsobem (např. ne roboty a slídily přes cURL, ale reálnými uživateli tvých stránek). U operací, které něco mění (například mažou nějaké položky v databázi) by response-challenge nemělo chybět. Buď můžeš využít výše zmíněné knihovny/devstacky apod. nebo si to napsat sám - není to až tak těžké.