Devo evitare questo schema di autenticazione basato su token (che non è OAuth)?

Naviga le tue risposte
7

Ho già avuto a che fare con OAuth ma non sono molto sicuro dell'API con cui sto lavorando ora. La mia domanda è fondamentalmente, è tristemente insicuro ?

A quanto ho capito, oAuth fa quanto segue (approssimativamente):

  1. Il servizio X mi fornisce una chiave e un segreto

  2. Chiedo all'utente di concedermi l'accesso al servizio X

  3. Invio la chiave e il segreto al servizio X per verificare. Il servizio X mi fornisce un token di richiesta, che invio con l'utente.

  4. L'utente conferma che vuole lasciarmi entrare, e il servizio me li restituisce con un token che posso conservare nel mio database e utilizzare per effettuare chiamate API di servizio per loro

  5. Ad un certo punto il token scade, ma il servizio sa chi sono, quindi posso semplicemente chiederne uno nuovo

Tuttavia, l'API di cui sto trattando funziona in questo modo (su https, obv):

  1. Mi forniscono una chiave API.

  2. L'utente mi fornisce il nome utente e la password

  3. Li trasmetto al servizio insieme alla mia chiave API, quindi li scarto

  4. Il servizio mi restituisce un token che posso utilizzare per effettuare chiamate API per loro conto (utilizzando il token e la mia chiave API), che memorizzo nel mio database.

  5. A un certo punto, il token scade e ho bisogno di riceverne uno nuovo in modo che l'utente debba autenticarsi di nuovo.

Ho ragione nel ritenere che i principali punti deboli di questo schema rispetto a OAuth siano i seguenti?

  • non c'è alcuna garanzia che la richiesta provenga dal mio server, quindi se qualcuno ha fatto irruzione nel mio db, potrebbe fare chiamate API a volontà per tutti i miei utenti, usando la mia chiave API, che potrebbero ottenere dall'analisi del POST che ho da inviare quando si autentica un determinato utente
  • Devo continuare a riautenticare l'utente con una password, ecc. perché è fondamentalmente pericoloso avere questi dati in giro
  • Sono obbligato a fornire una connessione HTTPS affinché l'utente possa digitare la sua password di servizio in primo luogo

Non è una questione di vita o di morte - non sono i conti bancari delle persone ecc. - ma sarebbe bello essere ragionevolmente sicuri che non ci sarà una datapix di Exxon Valdez.

Grazie per qualsiasi aiuto o consiglio.

    
posta djb 13.09.2012 - 09:32
fonte

2 risposte

4

Inizialmente mi viene in mente: "L'utente mi fornisce il nome utente e la password"

Con il loro nome utente e password puoi fare molti danni. Con OAuth è più semplice avere un controllo granulare dell'accesso.

    
risposta data 13.09.2012 - 18:31
fonte
2

La mia principale preoccupazione sarebbe quella di dover gestire il nome utente e la password dell'utente. Non sono sicuro di vedere come i token differiscono davvero. OAuth offre la possibilità aggiuntiva per le tue informazioni di essere registrate al servizio in modo che tu possa autenticarsi nuovamente in futuro, ma alla fine, se il tuo DB è compromesso, probabilmente c'è una buona possibilità che le tue chiavi API siano pure. In tal caso, il token sarebbe comunque utile a un utente malintenzionato fino alla scadenza, ma non sarebbe in grado di ottenerne uno nuovo nel secondo sistema.

Dal punto di vista funzionale, a seconda di come funziona lo storage delle chiavi, OAuth potrebbe presentare un leggero vantaggio, ma in realtà la principale differenza significativa consiste nel dover inoltrare le credenziali personalmente.

    
risposta data 13.09.2012 - 20:37
fonte

Leggi altre domande sui tag

È un modo sicuro per dichiarare i parametri DB in htaccess piuttosto che in un file PHP? Non è OpenID su HTTP (non HTTPS) fatalmente imperfetto quando vengono utilizzati i delegati?