Ha senso creare un'interfaccia API completamente nuova per gestire solo la chiave segreta web?

1

In OAuth2.0 dobbiamo inviare l'id del client e il segreto insieme alle credenziali dell'utente per ottenere un token di accesso da un server di autorizzazione. Abbiamo un'applicazione web ReactJS che deve inviare la sua richiesta al gateway API (API principale), ma il problema sorge quando l'applicazione web vuole memorizzare il client segreto per le sue richieste:

Inquestoscenariosonoperfettamenteconsapevolechel'archiviazionedelsegretosull'appWebesponeilsegretoaInternetWILDetuttipossonocreareunanuovaapplicazionedazeroeinviarlaalgatewayAPI.

CiòchemièvenutoinmenteècreareungatewaymiddlewaresulserverchememorizzerebbeilsegretoelasuainterafunzionalitàsarebbeottenereuntokendiaccessodalgatewayAPItramiteilsuosegretoel'iddelclientcheèdatodaReactJSwebapplicazione. L'interaresponsabilitàdiSecretHolderèchemantienesoloilsegretoperl'applicazionewebeottieneuntokendiaccessoperl'appReactJS.

HoesaminatotutteledomanderiportatediseguitomanonsonoriuscitoasoddisfarelamiaideadiprogettareunmoduloaggiuntivoperlasemplicepubblicazioneditokendiaccessoperilWeb:

In futuro avremmo sicuramente iOS & Anche Android di applicazioni.

Come gestisci il tuo ID cliente e amp; segreto nelle tue applicazioni web? Il secondo scenario è abbastanza buono o esiste una best practice di cui non sono a conoscenza?

Apprezzerei se qualcuno potesse far luce su questa domanda.

    
posta ALH 07.12.2017 - 16:19
fonte

2 risposte

1

La tua versione di tl; dr è "ovviamente no", ma il problema di fondo qui è un misunderstadning fondamentale e molto comune di ciò che secret significa in realtà in questi contesti.

Per prima cosa, non c'è assolutamente modo di garantire che un segreto rimanga ... beh ... segreto quando viene distribuito alle app del cliente; questo indipendentemente dal fatto che siano basati sul web o in altro modo (per esempio mobile o IOT).

In effetti, usando < Cognito come esempio, menzionano anche esplicitamente quanto sopra nel loro doc sulle app e sui segreti dei clienti :

If a secret is created for the app, the secret must be provided to use the app. Browser-based applications written in JavaScript may not need an app with a secret.

E per una buona ragione: a che serve un segreto in un'app browser in cui chiunque può fare clic con il pulsante destro del mouse in pochi secondi?

E anche per i clienti distribuiti in modo "confezionato" senza accesso diretto al codice sorgente come app mobili, segreti può ancora essere ripristinato ; tutto ciò che puoi fare è offuscarli e sperare che nessuno decida che veramente devono trovarli. Sono solo un inconveniente per chiunque stia tentando di fare qualcosa di sospetto.

Le comunicazioni segrete effettive possono essere attivate con flussi che coinvolgono un "server intermedio", ma si riferiscono alle specifiche della situazione. Ad esempio, prestito da Cognito di nuovo :

For security reasons, we highly recommend that you use only the Authorization code grant flow, together with PKCE, for mobile apps.

La cosa fondamentale da ricordare è se lascia l'app / fa parte di una richiesta che non è un segreto , e anche se ciò non è possibile è comunque possibile che venga compromessa.

Ricorda che quanto sopra è valido per i segreti dei clienti / chiavi API quando si tratta di chiamate non autenticate (es. chiamate di iscrizione o chiamate API per ottenere un elenco di prodotti su una piattaforma di e-commerce) solo . Le chiamate autenticate sono una cosa diversa e richiederebbero un qualche tipo di attacco MITM o accesso fisico all'account attaccato per poterne ottenere.

Riassunto:

  1. I segreti dei clienti e le chiavi API distribuite alle app dei clienti sono semplicemente fuori dal tuo controllo per mantenere segreti per definizione e come tali dovrebbero in ogni momento essere considerati buoni come compromessi .

  2. Conoscendo quanto sopra, e supponendo di voler "tenere le persone lontane" puoi includere una strategia di rotazione per i segreti pubblicamente distribuiti per rendere più difficile / scomodo per le persone arrivare a loro e (a seconda di quanto impegno vorresti spendere) identificarli potenzialmente.

  3. Dovresti comunque usarli per le app per dispositivi mobili in combinazione con PKCE , semplicemente offuscali al meglio delle tue capacità, in primo luogo, per ridurre al minimo il potenziale di esposizione ( se e solo se li stai utilizzando per calcolare qualcosa come un HMAC localmente o usando un altro modo per proteggerli come SSL pinning ) ma tieni presente che anche allora le persone continueranno a capire come scoprili .

risposta data 27.04.2018 - 16:43
fonte
0

Devi solo avere l'id del tuo cliente e le modifiche segrete in ogni richiesta per l'app, farlo scadere presto e magari collegarlo anche a un token di aggiornamento. Se si desidera impedire l'accesso a un client, revocare il token di aggiornamento. Archivia il tuo segreto client dinamico in cookie sicuro e assicurati https.

    
risposta data 28.04.2018 - 22:08
fonte

Leggi altre domande sui tag