Protezione di un'API REST e Slim Framework

Question

Sono abbastanza nuovo per le API REST e mi rendo conto che ci sono già alcune domande già pubblicate. Tuttavia, la lettura di questi mi ha effettivamente lasciato più confuso su come gestirlo.

Ho creato un'API REST utilizzando Slim Framework che sto semplicemente utilizzando per trasferire i dati. Non userò l'accesso utente o l'autenticazione, quindi credo che per garantire questo ho solo bisogno di un sistema che utilizza una chiave pubblica e una chiave privata, ma non sono sicuro.

Se qualcuno ha idea del modo corretto/più sicuro per farlo, o di qualsiasi tutorial/risorsa che sarebbe bello. Qualsiasi aiuto è apprezzato.

Answer 1

È possibile utilizzare SSL per crittografare i dati in transito.

Ma SSL è solo crittografia; ssl lato server non esegue l'autenticazione del client, né l'autorizzazione. Puoi pensare all'autorizzazione come rispondere alla domanda il chiamante è autorizzato a fare ciò che sta chiedendo?. Autenticazione che stabilisce l'identità del chiamante o L'autenticazione è di solito un primo passo necessario per l'autorizzazione. A volte non hai bisogno di "tutta l'identità" - devi solo accertarti di un aspetto particolare. Ad esempio, un cancello automatizzato non avrebbe bisogno di sapere chi era, ma solo se fossi maschio o femmina per accertare l'identità. Allo stesso modo, a certi servizi non importa chi sei; consentiranno l'accesso se si sta chiamando da una rete particolare (whitelist IP) o se si possiede un token speciale.

per consentire al server di distinguere tra chiamate autorizzate e non autorizzate avete alcune opzioni:

• IP whitelist. Se si conosce l'indirizzo IP dell'app o dell'agente che chiamerà il servizio, è possibile specificarlo nell'implementazione del servizio. Il servizio può controllare l'IP delle richieste in arrivo e respingere quelli che non sono nella whitelist. Questa è una sorta di autorizzazione "implicita" basata sull'indirizzo del chiamante.

• un token segreto, che l'app fornisce in ogni chiamata. Hai detto che non volevi fare l'autenticazione, ma questa è una forma di autenticazione. Potresti chiamarlo "gettone portatore". Chiunque porti questo segnalino ottiene l'autorizzazione. Nel tuo server controlleresti il ​​valore del token e rifiuterai qualsiasi chiamata che non corrisponde al valore noto. Funziona in modo simile alla whitelist IP, tranne che il token è passato esplicitamente e non ha alcuna relazione con l'indirizzo di rete.

• un token + coppia di chiavi. Questo è come un nome utente/password, ma può essere utilizzato per autenticare l'app. Usalo per fornire l'identità dell'app stessa. Controlla sul lato del servizio come sopra.

• nome utente/password. Per autenticare l'utente dell'app.

Si consiglia di combinare questi per produrre la soluzione desiderata. In altre parole, la richiesta del cliente deve essere dal giusto indirizzo, e deve avere un token/chiave per l'app, e un nome utente/password per l'utente, per poter essere considerato "autorizzato".