Sicurezza per l'API REST "privata"

Question

Attualmente sto sviluppando un'applicazione web che al momento comprende un front-end che visualizza e interagisce con i dati utilizzando un'API REST che abbiamo scritto. L'unica cosa che userà mai l'API è il nostro sito Web di front-end e, a un certo punto, un'app mobile che svilupperemo.

Ho letto molto su come OAuth sia il meccanismo ideale per proteggere un'API e a questo punto sto iniziando ad avere una buona comprensione di come funziona.

La mia domanda è: poiché non concedo mai l'accesso alla mia API a un client di terze parti, OAuth è davvero necessario? C'è qualche ragione per cui è vantaggioso? Inoltre, poiché il back-end è semplicemente l'API, non esiste un gateway per l'autenticazione da parte di un utente (come se stessimo scrivendo un'app utilizzando l'API di Twitter, quando un utente autentica verrebbe indirizzato alla pagina Twitter per concedere l'accesso quindi reindirizzato al client).

Non sono davvero sicuro su quale direzione andare. Sembra che ci debba essere un approccio a metà strada tra l'autenticazione HTTP e OAuth che sarebbe appropriato per questa situazione, ma non lo capisco.

Answer 1

OAuth a 2 gambe è probabilmente quello che si desidera utilizzare. È fondamentalmente un hashing di una chiave condivisa, ma hai il vantaggio di non dover scrivere il codice da solo.

Ecco una domanda correlata: Two-legged OAuth - looking for information

Answer 2

si consiglia di utilizzare OAuth per dispositivo mobile per la comunicazione livello API.

Tuttavia, non c'è alcun vantaggio di Oauth in questo livello di interfaccia utente Web per l'accesso di livello intermedio (da macchina a macchina).

D'altra parte ci sono alcuni potenziali problemi di

1. Gestire l'accesso di scadenza del token diventa un dolore. Considera che l'interfaccia utente deve memorizzare nella cache il token di accesso su più nodi in un cluster. Aggiungilo quando è scaduto e il fatto che il livello dell'interfaccia utente stia negoziando la sicurezza con il backend richiederà solo più tempo ogni tanto.

2. In Oauth a due gambe (credenziali client OAuth come nella versione 2.0) non supporta alcuna crittografia. Quindi è ancora necessario inviare la chiave e il segreto sia al server per ottenere un token di accesso.

3. backend deve implementare l'emissione di token di accesso, token di aggiornamento, convalidando token di accesso, ecc, senza alcun vantaggio significativo

Answer 3

Dal mio punto di vista, uno degli scenari che favoriscono OAuth rispetto ad altre opzioni è quello di lavorare con clienti non fidati, non importa se questi sono sviluppati da voi o da una terza parte.

Che cos'è un client non attendibile? Pensa dal punto di chi gestisce le credenziali che concedono l'accesso alla tua API.

• Ad esempio, l'applicazione web potrebbe interagire con l'API in due falvors:

  1. tua applicazione web parla lato server per la vostra API.Il tuo server di applicazioni Web è un client affidabile poiché le credenziali per accedere all'API possono essere accessibili solo da chi ha accesso al server ... Tu e il tuo team. Potresti autenticare il tuo server di app Web con un client_id e un client_secret.
  2. È possibile effettuare chiamate direttamente all'API dal client dell'app Web, che viene eseguito sul browser dell'utente finale utilizzando JavaScript. Il browser dell'utente finale è un client non attendibile. Se dovessi consegnare le credenziali alla tua API fino al browser, chiunque potrebbe controllare il codice JavaScript e rubare le tue credenziali.

• Anche un'app nativa di terze parti non è affidabile. Uno sviluppatore malintenzionato che utilizza la tua API potrebbe salvare le credenziali e l'utente finale della tua piattaforma.

• La tua app nativa è un client fidato e potrebbe gestire l'autenticazione con un semplice username, password e un id cliente che identifica la tua app.

In che modo OAuth può essere d'aiuto? OAuth Authorization code e Implicit le concessioni possono aiutarti con questo problema. Questi flussi funzionano solo con client che supportano un reindirizzamento, come un browser. E consente di autenticare un client non attendibile e un utente contro il server di autorizzazione per accedere al server di risorse, all'API, senza esporre le credenziali. Dai uno sguardo allo RFC per vedere come è fatto.

La cosa buona di OAuth è che non supporta solo questi flussi di autenticazione di reindirizzamento, ma supporta anche le credenziali del client e le credenziali dell'utente. Quindi un server di autorizzazione OAuth coprirebbe tutti i casi.

Answer 4

OAuth 2.0 inizialmente sembra una PITA se si pensa di doverne costruire molto da soli, ma la maggior parte delle lingue ha alcune configurazioni OAuth 2.0 davvero solide che è possibile inserire con quantità variabili di manipolazione. Se stai usando un framework come Laravel o RoR, allora non ha praticamente alcun lavoro.

• PHP: http://oauth2.thephpleague.com/
• di Ruby (Rails o d'uva): https://github.com/doorkeeper-gem/doorkeeper

Se non si desidera reindirizzare gli utenti come suggerito nel tuo post poi ignorare altri commenti e le risposte che parlano di due flussi di gambe. È possibile utilizzare il tipo di sovvenzione client_credentials per fare in modo che le app forniscano il proprio ID client e il segreto in cambio di un token di accesso, il che è semplice e facile.

Vorrei chiedere in che modo parliamo di privato, perché se gli unici sistemi che parlano con esso sono all'interno del backend e non hanno alcuna interazione con il mondo esterno, probabilmente lo si potrebbe lasciare aperto e basarsi solo sulla rete per tenerlo al sicuro (VPN/firewall).

Ma se è privato nel senso di "la nostra app per iPhone lo usa", allora sicuramente vuoi andare con OAuth 2.0, o qualcosa del genere.