Sto progettando un back-end basato sul web per un servizio online. Il servizio potrebbe supportare portali web e app mobili come front-end.
Ma sono bloccato su come supportare front-end di terze parti, cioè siti Web non attendibili. In effetti lo stesso problema esiste con le app mobili, anche se forse in misura minore.
In breve il problema è che l'autenticazione e l'autorizzazione dovrebbero avvenire nel back-end, e la domanda è come garantire che un portale di livello intermedio o un portale web non salvi le credenziali segrete di un utente o attraverso altri mezzi possa rappresentare un utente finale ed eseguire operazioni che l'utente non sta richiedendo!
Devo essere in grado di autenticare l'utente finale nel back-end e attualmente ho un proof-of-concept funzionante, e i processi di registrazione e autenticazione per questo sono i seguenti:
- Nuovo utente si connette alla pagina di registrazione pubblica.
- Forse include JS per generare una coppia di chiavi pubblica / privata?
- Autorizza l'accesso al provider Oauth per informazioni di base sul profilo.
- Recupera i dettagli dell'utente e popola il profilo.
- L'utente fornisce informazioni aggiuntive (ad es. numero di contatto, indirizzo email di recupero) e la sua chiave pubblica per completare la procedura di registrazione.
E quindi il processo di autenticazione per un utente di ritorno sarebbe qualcosa come:
- L'applicazione utente (Android o Javascript) crea una richiesta formattata JSON.
- L'applicazione firma la richiesta con la chiave privata dell'utente.
- L'applicazione allega l'identificazione dell'utente (id-utente / id-aperto / ecc.) alla richiesta.
- L'applicazione invia la richiesta all'API (back-end).
- API verifica che la richiesta sia autenticata per l'utente specificato (verifica firma)
- API verifica che le richieste siano autorizzate.
- I processi API richiedono e costruiscono la risposta.
- API crittografa la risposta utilizzando la chiave pubblica dell'utente.
- l'API allega alcune informazioni di base (es. versione API e identificativo della richiesta) alla risposta.
- API restituisce la risposta nella sessione HTTPS dell'utente.
Per quanto posso dire, il problema arriva al punto 4. L'applicazione può inviare la richiesta ovunque, ad esempio un sito Web di terzi che aggiunge vantaggi come la formattazione e le funzioni avanzate. Ciò significa che il livello intermedio invia più query al back-end per conto dell'utente finale, crea la risposta e restituisce la pagina o il report all'utente.
Tra l'altro spero di sfruttare due vantaggi specifici dell'uso di openid / oauth (che non ho ancora avuto modo di lavorare nella mia implementazione proof-of-concept)
a. Rendi facile il processo di registrazione: l'utente non ha bisogno di ricordarlo una nuova password e non ha bisogno di compilare tutti i loro dettagli, solo i bit necessari per l'applicazione che non sono forniti da Google+ e amici.
b. Non ho bisogno di gestire password dimenticate / reset della password in 99% dei casi. Finché l'utente ha accesso al proprio open-id account possono riacquistare l'accesso al servizio. Quando ci si connette da un nuovo dispositivo, ad esempio un secondo PC / tablet / altro, l'applicazione crea una nuova coppia di chiavi pubblica / privata e la parte del provider openid dà accesso al profilo dell'utente. Se l'utente passa a un nuovo provider openid può utilizzare l'indirizzo email di recupero per collegare un nuovo URI openid al suo profilo sul sistema.
D'altra parte non sto cercando di integrarmi con altre funzionalità più avanzate dei provider openid in questa fase. Voglio davvero che una terza parte gestisca il lavoro svolto per identificare gli utenti e gestire le loro password.
Il problema è che l'utente si registra con il back-end attraverso un'interfaccia che potrebbe non essere attendibile. Un livello medio non valido può potenzialmente sostituire la chiave pubblica di un utente per una chiave pubblica per la quale controllano la chiave privata. Come posso progettare questo tipo di situazione? Disabilito completamente le interfacce di terzi verso il back-end (preferirei non essere coinvolto con le app e i siti web, anche se implementerò un'applicazione di riferimento)