Sto cercando di implementare un sistema per le app di terze parti per accedere ai dati archiviati da un utente su un provider. Abbiamo un robusto sistema di controllo degli accessi, con lettura / scrittura separata / ecc. livelli per ogni "flusso" di dati pubblicati da un utente. All'interno del nostro sito web, questi livelli di accesso sono già applicati a seconda di quale utente sta tentando di eseguire l'azione con lo stream di un altro utente.
Ora arriva il momento di consentire alle app di terze parti di fare lo stesso, in un modo compatibile con outh2. Attualmente rappresentiamo app di terze parti all'interno del database dell'app fornitore come utenti regolari con un id utente, un URL canonico, ecc. Quindi, questo id utente sarebbe l'id_cliente dell'app.
La mia domanda è, perché oAuth ha affatto token, che sono essenzialmente stringhe opache che mappano (user_id, client_id) record che hanno (scope, ecc.)?
L'app non può identificarsi semplicemente con client_id come sua chiave API e firmare le sue richieste con un segreto simmetrico, per le richieste da server a server? Queste richieste e risposte firmate possono essere inoltrate tramite un agente utente, se necessario, se è necessario che un utente sia online quando la richiesta è concessa.
Il provider memorizza già i record di accesso per (user_id, client_id) in modo che sappia se approvare o rifiutare una richiesta dall'app client. Perché l'app del client deve memorizzare e sputare i token extra?
L'unica cosa che ho scoperto finora è forse aumentare la sicurezza nel caso in cui qualcuno ottenga un accesso non autorizzato al segreto simmetrico della app del client. E in questo modo l'attacco sarebbe limitato a tutti i token che sarebbero in grado di ottenere (poiché i token sono richiesti come ulteriori credenziali). Sembra che sul lato server, se qualcuno ottiene il segreto simmetrico, probabilmente ottengono anche le credenziali del database. Quindi questo non è un gran vantaggio.
C'è qualche altra ragione? O era solo un teatro di sicurezza?