Cum ofer un API


(Andrei Luca) #1

Salut
Nu stiu ce alt titlu mai bun sa pun.
Vreau sa fac un API pe care sa il ofer contracost. Cum fac sa securizez acest API sa poata fi accesat de un alt serviciu?
Ofer un token privat pe care cel care ma apeleaza il va pune in header-ul HTTP requestului?
Ce alte metode ati mai folosit / intalnit?
Daca a inteles cineva mai bine ce vreau sa fac si poata sa explice un pic mai bine, va rog.


(Alex) #2

uita-te la jwt.


(Andrei Luca) #3

Am observat ca unele aplicatii care ofera API-uri iti ofera un token atunci cand faci signup pe care sa il folosesti cand faci apeluri (token care presupun ca trebuie pus undeva ori in header-ul requestului ori in body?)
Totusi, tu ai nevoie de acest token in frontend, corect? Asta nu face fff vulnerabil API-ul? Daca iti ia cineva token-ul ala, face face milioane de requesturi ->> denial of service?

Mentionez ca nu am mai lucrat pana acum cu API-uri externe (gen private / platite) si nu prea stiu cum functioneaza treaba asta.


(Andrei Luca) #4

Stiu de JWT. Acum is curios sa vad si ce alte metode mai exista pe piata. Gen asta pe care am scris-o mai sus. Pare ca e un token hardcodat care nu se schimba (asa cum e in cazul jwt care are data de expirare)


(Horia Coman) #5

Depinde și ce face API-ul asta și cine trebuie să-l apeleze. Cel mai comun caz este cel al unui apel dintr-un backend al clientului, o zona protejata cum ar veni. Iar pentru asta in shared secret e deajuns (un API key cum ii zici). Poți impune restricții extra precum apelul să provină doar de la un IP de exemplu. Pe partea de client side restrictii de genul app ID sau referrer ajuta ceva, dar nu împotriva celor mai determinați “atacatori”. Baga mai multe detalii și putem ajuta mai precis.


(Ionuț Staicu) #6

Gândește-te la cum funcționează API-ul de la youtube sau facebook: faci auth pe server iar toate request-urile se fac din server. Practic ai flow de genul:

client -> server -> api
api -> server -> client

(Opencart Romania) #7

Salutare!

Intrebarea este incomplata si foarte generala.

A oferi cuiva un API, presupune mult mai multe decat un simplu token … (care da poate fi folosit ptr. autentificare / identificarea a unui request)

Cred ca mai bine cauta ceva documentatii legate de modul in care te poti folosi de o astfel de metoda.

Mult Success!


(Andrei Luca) #8

Are legatura cu faptul ca nu prea stiu exact cum sa explic ce vreau :))
“presupune mult mai multe decat un simplu token” -> poti da mai multe detalii? nu doar pentru mine neaparat cat si pentru valoarea acestui topic


(Andrei Luca) #9

Ce zici tu are oarecum legatura cu ce a zis Horia mai sus, nu?

Cel mai comun caz este cel al unui apel dintr-un backend al clientului, o zona protejata cum ar veni. Iar pentru asta in shared secret e deajuns (un API key cum ii zici)


(Andrei Luca) #10

Cred ca flow-ul o sa fie ceva de genul
client -> server 3rdparty -> api-ul meu -> server-ul meu -> alta masina care face calculele si retur
Lucru care cred ca se poate rezolva asa cum a zis Horia. Shared secret salvat in baza mea de date pe care il dau la 3rd party si de fiecare data cand se apeleaza una din rutele expuse din API verific sa vad daca requestul are un key si daca se afla printre cele din baza de date.
@tekkie? de obicei mai dai cate-o resursa misto :))


(Ovidiu L.) #11

@Andrei_Luca hai sa ne gandim cum am face in realitate? Daca eu vreau sa iti trimi un mesaj cum fac? daca sunt si alte persoane de fata si nu vreau sa stie ce ti-am transmis?

Folosesti 2 key: (server <-> client)

  1. Public: pentru identificare clientului (asa numitul token): header (preferabil)
  2. Privata: pentru a descifrarea continutul (mesajului): body

evitarea de atac DOS se face in funtie ce destinatia API;
ex: 1. ca daca ai un API ce serveste pentru tranzactionare (gen bursa/order), evitarea DOS se face prin limitarea de requesturi per secunda/minut
ex: 2. daca API ce face update-uri multe (POST/PUT) intr-o aplicatie se poate face prin balansarea bazelor de date.


(Horia Coman) #12

Nb: considera shared secretu-ul ca o parola și aplica aceleasi standarde de securitate pentru ea . Gen nu o stoca simplu in db, ci doar că un hash.
Nbb: hashul poate fi și non-password, pentru că tokenul (dacă îl emiți printr-o metoda de randomness crypto) o să aibă deajuns entropie încât brute-force-uri sa nu fie fezabile chiar cu sha3.

Ce descrii tu pare un use-case decent. De referință, API-urile comerciale de la Google tot același mecanism au. Poate pentru lucru în finanțe etc îți trebuie sisteme public/private, tokenuri de sesiune, oauth etc


(Emanuel Gug) #13

Pentru a preveni abuzurile, poţi face un mecanism de renewal, gen tokenul expiră după 24 ore şi trebuie generat un token nou.

De ex, la generarea unui token, le dai 2 hashuri: unul e tokenul care trebuie folosit, şi un refresh token care poate fi folosit doar la reînnoire, şi poate fi folosit o singură dată.

Astfel cine fură tokenul din requesturi, nu poate face mare lucru cu el. Iar dacă îl dă la altcineva, dacă celălalt foloseşte tokenul de reînnoire, primul nu-l mai poate folosi, şi devine prea complicat ca să se merite.