Decide di eseguire la sicurezza dell'API REST

6

Ho sviluppato un'API. Mi sono confuso e ho letto articoli per giorni. In realtà la mia domanda è vicina a queste ma non esatta (forse una combinazione di esse);
Protezione dell'API REST a cui si accede da diversi client
API REST senza login per pochissimi clienti

Devo fornire sicurezza alla mia API. L'API verrà utilizzata dalle applicazioni client di terze parti. Ho allegato uno schema qui sotto.

Che cosa dovrei fare?

HTTP-Basic con SSL \ TLS, HTTP-Digest con SSL \ TLS, OAuth 2.0 o cos'altro dovrebbe essere?

Modifica(25/03/2015):
Questaparteèstataabbandonata.Guarda"Modifica (2015-04-01)" in basso

Ho deciso di implementare SSL + OAuth 2.0 ( Concessione di credenziali password del proprietario di risorse ). Se ritieni che non sia conveniente per lo scenario, ti preghiamo di informarmi.

 +----------+
 | Resource |
 |  Owner   |
 |          |
 +----------+
      v
      |    Resource Owner
     (A) Password Credentials
      |
      v
 +---------+                                  +---------------+
 |         |>--(B)---- Resource Owner ------->|               |
 |         |         Password Credentials     | Authorization |
 | Client  |                                  |     Server    |
 |         |<--(C)---- Access Token ---------<|               |
 |         |    (w/ Optional Refresh Token)   |               |
 +---------+                                  +---------------+

        Figure 5: Resource Owner Password Credentials Flow

Il flusso illustrato in Figura 5 include i seguenti passaggi:

(A) Il proprietario della risorsa fornisce al client il suo nome utente e         password.

(B) Il client richiede un token di accesso dall'autorizzazione         endpoint del token del server includendo le credenziali ricevute         dal proprietario della risorsa. Quando si effettua la richiesta, il cliente         si autentica con il server di autorizzazione.

(C) Il server di autorizzazione autentica il client e lo convalida         le credenziali del proprietario della risorsa e, se valido, emette un accesso         token.

Modifica (2015-04-01):

Ho implementato Credenziali client OAuth 2.0 . E ora sto cercando come implementare un certificato SSL per la richiesta dell'API dei clienti.

Le credenziali del cliente che concedono il tipo DEVONO essere utilizzate solo da riservate    clienti.

 +---------+                                  +---------------+
 |         |                                  |               |
 |         |>--(A)- Client Authentication --->| Authorization |
 | Client  |                                  |     Server    |
 |         |<--(B)---- Access Token ---------<|               |
 |         |                                  |               |
 +---------+                                  +---------------+

                 Figure 6: Client Credentials Flow

Il flusso illustrato in Figura 6 include i seguenti passaggi:

(A) Il client si autentica con il server di autorizzazione e         richiede un token di accesso dall'endpoint del token.

(B) Il server di autorizzazione autentica il client e, se valido,         emette un token di accesso.

    
posta efkan 25.03.2015 - 17:25
fonte

2 risposte

6

Ciò che direi delle opzioni da te delineate è che HTTP Auth con SSL è un'opzione più semplice ma meno flessibile e Oauth2 è più complesso ma ha una maggiore flessibilità in ciò che puoi ottenere con esso.

Un esempio, come hai notato nel tuo diagramma artistico ASCII, con OAuth2 è possibile creare un token che può essere usato al posto della password per autenticare le richieste. Questo è probabilmente un vantaggio rispetto a HTTP Basic / Digest poiché significa che non devi memorizzare la password degli utenti sul client, puoi semplicemente archiviare il token.

Quindi in generale se puoi implementare bene OAuth2, direi di andare con quello ...

    
risposta data 25.03.2015 - 21:47
fonte
5

Se un token OAuth 2.0 è compromesso, devi solo preoccuparti per il TTL del token.

Se un'intestazione di autenticazione di base HTTP viene compromessa, le credenziali non scadono. Dovresti manualmente cambiare il tuo client_id e il tuo segreto, e questo è il caso che tu sappia o pensi che siano stati compromessi. Ed è probabile che dovrai modificare il codice cliente ogni volta per tener conto di ciò.

La differenza chiave tra queste 2 opzioni è che il conteggio dei token OAuth 2.0 comporta 1 passaggio critico in cui client_id e segreto vengono scambiati. Nell'autentica base HTTP, ogni singola chiamata API coinvolge lo stesso scambio.

Da questa prospettiva, OAuth 2.0 è un'opzione molto più sicura.

    
risposta data 25.03.2015 - 22:58
fonte

Leggi altre domande sui tag