Zabezpečení systémové API rubrika: Programování: PHP

4 zvitek
položil/-a 8.2.2015

Zdravím,
ze svého systému umožnuji uživatelům přistupovat k datům pomocí REST API.
Né všechny data jsou ale přístupná pro všechny a tak hledám nejlepší řešení, jak je zapezpečit. Mám v hlavě nějaké idee jako nějaký access token, SSL, přihlašování apod.
Zajímal by mne váš pohled na optimální řešení. Nejedná se o nějaká super tajná data, takže nehledám nic světoborného, ale zase nechci jenom posílat nějaký klíč jako parametr v url. Díky za názory

Komentáře

odkaz
5 Víťa Plšek - an...
odpověděl/-a 14.2.2015

Vyloučím posílání hesla v požadavku a cookies(které bude fungovat, ale je to spíš vedlejší efekt).
Rozhodně chceš tedy použít nějakou formu tokenu. Tedy něco co vygeneruje server, předá klientovi a ten mu jej potom posílá a tím se identifikuje.
Musíš zajistit, aby jej nikdo neodposlechl, ale potom je to poměrně dobré řešení.

Máš dvě možnosti. Buť server vygeneruje token a ví, že jej vygeneroval a tím může řídit platnost a kdo je přihlášený.
Nebo a za co bych se přimlouval, použiješ token, který když vygeneruješ, nikam neukládáš ale jen předáš klientovi.

Pro klienta se vlastně nic nemění. S tokenem pracuje tak, že jej přikládá k požadavkům, většinou se tak děje v nějaké hlavičce.
Může v něm mít uložená i nějaká data, která využije (informační část je jen base64 zakódovaný json).

Rozdíl je pak jen v implementaci na serveru.
Aktuálně populární metodou je JWT - Json Web Token
Je kolem toho v poslední době velký Hype a spousta článků to popisuje složitějc než to je.

Funguje to tak, že poté co odešleš přihlašovací údaje na server, tak po jejich ověření server vygeneruje token.
Token se zkládá z identifikační části, kterou převedeš do base64 a vypočteš k ní hash pomocí HMAC s heslem, které zůstává jen na serveru.

Tyto dvě části spolu s hlavičkou jsou poté tokenem. Informační část je čitelná, a můžou v ní být i informace využitelné klientem. Změnit ji nikdo nemůže kvůli hashi.
Server si token nikde neukládá, jen ho předá klientovi, je to vpodstatě taková čipová kartička.

Přikládáš ho pak k požadavkům, server si z informační části načte info o uživateli, a hash v tokenu zkontroluje s vypočteným hashem stejným způsobem jako při vytvářeni.
Informační část může obsahovat jakákoli data, například dobu expirace, nebo seznam rolí pro klienta.

Jak to funguje můžeš juknout tady(to je vlastně to, co dělá server) - modrá část je ta informační, červená je podpis - http://jwt.io/

Jediné co potřebuješ je nějaký Helper, který na straně serveru token spočítá a ověří, na odkaze výše je spousta odkazů, bude tam něco i pro PHP.

Pár článků, které mi s tím docela pomohli ( že je to java ignoruj, princip je všude stejný - vytvořit token, přikládat ho k požadavkům a pak jej ověřit).

https://auth0.com/blog/2014/01/07/angularjs-authentication-with-cookies-...
http://blog.jdriven.com/2014/10/stateless-spring-security-part-2-statele...

Komentáře

  • diverman : V prvni vete jsi vyloucil cookies a pozdeji de facto popisujes sessionID v cookies ("""S tokenem pracuje tak, že jej přikládá k požadavkům, většinou se tak děje v nějaké hlavičce"""). 17.2.2015
  • Víťa Plšek - an... : Nevím jestli uplně rozumím. Ano, varianta, kdy server ví o tom, kdo je zalogovaný - tedy drží session je vpodstatě nějaká forma sessionID. Ale nejsou to cookies. Při použití jwt žádná session nevzniká. 18.2.2015

Pro zobrazení všech 4 odpovědí se prosím přihlaste:

Rychlé přihlášení přes sociální sítě:

Nebo se přihlaste jménem a heslem:

Zadejte prosím svou e-mailovou adresu.
Zadejte své heslo.