Accesso API di terze parti: OAuth è davvero necessario?

Tutto si riduce al vecchio adagio: "La buona sicurezza IT è difficile " .

Anche se nessuna delle preoccupazioni conosciute da noi qui è fatale (non possiamo conoscere la vostra intera azienda e il modello del cliente), sollevano seri dubbi o almeno cose per davvero pensare seriamente circa, e vale la pena di prendere in modo sobrio.

• Giralo e guarda la prospettiva dei tuoi utenti. Chiedete ai vostri utenti / clienti di investire tempo / denaro / risorse nell'apprendimento e sfruttando la vostra API (caso d'uso: un fornitore) rispetto a un'API ben nota standardizzata (caso d'uso: molti). Se si interrompe l'attività, il loro sforzo viene sprecato. Se vogliono riutilizzare il proprio lavoro, non possono facilmente trasferirlo o riapplicarlo senza ulteriori e forse proibitivi lavori che possono evitare non adottando quel percorso all'inizio. C'è una ragione per cui gli standard aperti sono aperti: potrebbero non essere adatti a tutti, ma hanno altri vantaggi nel quadro più ampio.

• Saranno anche preoccupati di quanto siano certi del beneficio a lungo termine di questo concetto per gli utenti. Possono prendere in considerazione e valutare la durata della tua attività, il tuo approccio, il tuo impegno in questo percorso e il loro impegno per il tuo impegno in questo percorso, e ad un certo livello valuteranno quanto sono certi che tu, il prodotto e il loro uso il prodotto sarà ancora in giro negli anni a venire (molti non lo sono). Che ne pensi dell'interoperabilità? Forse sarà una preoccupazione se i loro altri fornitori si preoccupino di includere alcune API minori e proprietarie o una ben nota che possono vendere come funzionalità ad altri utenti di loro, o se i dati possono essere eliminati in altri pacchetti senza dover scrivere "shim" per ciascuno. Vogliono il carico di manutenzione o dubbi che questo potrebbe sollevare?

• In terzo luogo, anche se le persone potrebbero volerlo, considera anche questo: che basi hai per credere che il tuo approccio sarebbe implementato in modo più sicuro rispetto alle versioni esistenti? Non è la stessa cosa di "design più sicuro". Una configurazione fatta in casa potrebbe essere molto più adatta e adatta alle tue esigenze, ma sei sicuro di avere la competenza e le capacità per progettare, e sviluppare un'implementazione di quel progetto , che resista al mondo reale di ITSec? Anche se pensi di poterlo fare, le terze parti di cui cerchi la fiducia, sono d'accordo con te completamente?

• In quarto luogo, si consideri che un framework che ha il proprio focus sugli sviluppatori, può rispondere in modo più rapido e affidabile ai cambiamenti nel mondo della sicurezza che lo riguardano, o sul lato positivo, emergenti nuovi standard / sviluppi. Avete le risorse della vostra azienda da impegnare a mantenere l'accento su mantenerlo aggiornato continuamente, una volta prodotto? (Potresti, non hai descritto l'attività). Pianifica un drenaggio delle risorse più grande del previsto.

La formulazione della tua domanda è indicativa e dovrebbe essere l'ultimo pezzo di cui hai bisogno:

I >>doubt if these are really required<< for our intended use. I think that the >>simpler implementation ... might do the job as well<<

In altre parole, non sembri convinto che ci siano dei veri svantaggi tranne che potrebbero avere caratteristiche e competenze extra che non ti servono. Ma anche così potrebbe valere la pena di usare il pacchetto anche se non è necessario tutto ciò che ha, a causa dei suoi altri numerosi vantaggi nel farlo. Dopotutto, poche persone usano "la maggior parte" delle funzionalità di qualsiasi software principale (l'umile MS Word attraverso i server Web Apache come esempi rapidi) eppure il software è usato, ma non tutte le funzionalità.

Come azienda, è probabile che il tuo obiettivo sia basato sulla fiducia (i tuoi + clienti), sulla velocità e sull'efficienza in termini di costi / tempi. Per la maggior parte delle aziende che considerano un'esigenza di sicurezza, una soluzione già pronta potrebbe battere regolarmente le mani riservate fatte in casa su tutti i principali fronti, anche se è più del necessario oggi.

Non ho letto tutti i dettagli che hai scritto, voglio solo fare un'osservazione generale: stai pensando di ri-implementare parte di uno standard esistente. Molto probabilmente, tra qualche mese capirai che hai bisogno di un'altra funzionalità e dovrai implementare ancora un po 'di quello standard. A meno che tu non sia un genio crittografo con un team dedicato di revisori, ci sono buone probabilità che tu commetta un errore (o molti di essi) lungo il percorso, sia nel design che nell'implementazione.

E per di più stai costringendo tutte le terze parti a imparare qualcosa di nuovo che è unico per il tuo sito. Quindi una terza parte che già sa come integrare OAuth non trae alcun beneficio dalle proprie conoscenze e deve dedicare molto tempo all'apprendimento del proprio schema invece di svolgere il proprio lavoro; se non già conoscono OAuth, non hanno il vantaggio di apprenderlo subito e di poter riutilizzare quella conoscenza la volta successiva. In ogni caso, le terze parti devono dedicare del tempo ad apprendere il tuo esclusivo metodo di autenticazione invece di sviluppare nuove fantastiche funzionalità: quindi perché dovrebbero sviluppare qualcosa che aiuti tu invece di sviluppare qualcosa per uno dei tuoi concorrenti che ha fatto integrazione più semplice?

NIH è una trappola sbagliata in cui cadere. Usa solo ciò che è già in circolazione.

Oltre alle risposte più orientate al business già fornite, penso che ci sia anche un vantaggio tecnico dall'uso di OAuth:

Una volta che l'app di terze parti (client OAuth) ha ottenuto il token di accesso OAuth, può utilizzarlo per effettuare richieste sia dal browser (ad esempio utilizzando richieste AJAX), sia dal back-end. (Correggimi se questo è sbagliato ...)

Con la soluzione personalizzata che avevo proposto, sarebbero possibili solo richieste dal browser: l'app di terze parti non ottiene mai alcun token di accesso, utilizza solo implicitamente il cookie di sessione del nostro sito Web senza mai saperlo. Ciò ridurrebbe la potenza della nostra API, dal momento che costringerebbe gli sviluppatori ad una particolare architettura. Il browser sarebbe sempre richiesto come "proxy" per passare i dati tra il nostro e il loro back-end.