Autenticazione OAuth - Segreti condivisi

Il concetto di proxy lascia a te la questione dell'autenticazione. Come sapete, l'idea di base è creare un servizio basato su server che sia una facciata per comunicare con Flickr. Le app UWP comunicano solo con il tuo servizio web, che a sua volta contiene i tuoi segreti e li usa per comunicare con Flickr, restituendo solo i risultati all'utente finale, senza mai rivelare i segreti.

Questo modello lascia a te la questione dell'autenticazione dell'utente finale. È possibile creare un meccanismo che costringa gli utenti delle app UWP ad autenticarsi individualmente con il proprio servizio web prima di comunicare con Flickr, oppure è possibile consentire loro di accedere al proprio servizio web non autenticato.

Tuttavia, anche se non sono autenticati, questo modello offre numerosi vantaggi critici.

1. È possibile monitorare l'accesso al servizio. Se i segreti sono incorporati nell'app, come hai notato, questi possono essere eliminati e abusati da un utente malintenzionato e non potrai mai conoscere la differenza e non avere la possibilità di intervenire. Se le richieste devono passare attraverso un servizio che controlli, hai la capacità di individuare schemi potenzialmente abusivi e, almeno, sapere cosa sta succedendo, e sperare di mitigare l'abuso, identificando e bloccando i client offensivi.

2. Se ci sono problemi con le credenziali, come se fossero bloccate o scadute e dovessero essere modificate, è possibile aggiornarle sul lato server senza dover inviare aggiornamenti ad ogni singolo client. Nel modello attuale, se i creds cessano di essere validi per qualsiasi motivo, tutti i tuoi client sono interrotti finché non puoi pubblicare un aggiornamento con nuovi segreti, e ogni client lo installa. In questo modello, i client vengono interrotti solo finché non si aggiornano i segreti sul servizio, e quindi funzionano magicamente di nuovo.

Per aggiungere all'eccellente risposta di Xander in merito al proxy, qui ci sono alcuni approcci alternativi comuni in nessun ordine particolare:

1. Chiedi a ciascun cliente di generare le proprie chiavi API (client_id / client_secret) per il servizio e caricarle nell'app. Ciò potrebbe implicare una riduzione dell'usabilità a seconda della procedura di configurazione del provider API.
2. Utilizza il flusso "password", in cui la tua app utilizza le effettive credenziali dell'utente per ottenere un token. Alcuni provider OAuth implementano questo flusso senza l'autenticazione del client per consentire ai client thick dove questo flusso è solitamente più accettabile.
3. Scarica la chiave API online all'avvio. Questo non è molto sicuro (l'utente può leggere la chiave dalla memoria) ma è una via di mezzo tra l'avere i tasti codificati e l'implementazione del proprio proxy. Permette la revoca / il rinnovo / la rotazione delle chiavi secondo necessità

L'opzione preferita sarebbe ovviamente il proxy, ma ogni app ha esigenze e vincoli diversi e alcune delle alternative potrebbero funzionare laddove altre non lo fanno.

Se ti capisco correttamente, vuoi fornire alcune informazioni private per un'applicazione che hai creato? Presumo questo è il caso.

L'hardcoding di qualsiasi informazione non è mai una buona pratica, a meno che non sia il numero di versione dell'applicazione. Per le applicazioni web è comune iniettare la configurazione tramite l'ambiente. Basta impostare le variabili ENV che possono essere eseguite sia su Windows che su Unix. Ciò consente anche di modificare la configurazione per server / host.

Alcuni framework forniscono uno speciale file di configurazione per tali impostazioni. Questo file è escluso dal controllo git / version e lo si crea per server. Questo è anche il luogo in cui sono memorizzate le impostazioni del database.