Dato un setup in cui le credenziali dell'utente sono memorizzate su un server, ma i servizi web saranno chiamati da client di terze parti, la seguente sembra ragionevole:
-
Quando i client vogliono accedere, inviano nome utente / password al server (su ssl, confermato contro hash di scrubbing salato memorizzato nel server db)
-
Il server verifica le credenziali e al momento della convalida crea token JWT che contengono l'id utente e lo firma con il lato privato della coppia di chiavi pubblica / privata RSA. (in particolare, utilizza i metodi di AppEngine per signing- link )
-
I client utilizzano la chiave pubblica e verificano che la firma sia corretta. Da quel momento in poi considerano l'utente loggato. Si noti che la chiave pubblica può essere fornita in bundle con il client, o richiesta dal server e memorizzata nella cache.
-
Sebbene il client ora consideri l'utente registrato nelle successive api, le chiamate al server continuano a fornire il token jwt, che conferma l'id utente e la firma con la stessa chiave pubblica (si noti che potrebbe essere un server diverso da uno che ha fornito il token iniziale). Pertanto, le operazioni più significative (come change password ) sono ancora controllate lato server, anche se con lo stesso token di quello fornito ai client. (cioè un client può mostrare ciò che vuole, ma l'azione reale conferma veramente con la chiave pubblica appropriata. Identificare i dati sull'utente, oltre al loro id, richiede anche una chiamata API per garantire ulteriormente i client comportarsi bene)
C'è qualcosa di sbagliato in questa immagine? Sembra che oauth2 insista su qualche altra chiamata - cioè il mantra secondo cui oauth è un'autorizzazione, non un'autenticazione, e quindi deve essere fatta una chiamata aggiuntiva deve (come "ottenere profilo") prima di considerare l'utente autenticato correttamente .
Perché è così? Quali vantaggi avrebbe oauth2 su questa metodologia per questo specifico caso d'uso?