Perché oAuth e oAuth 2 dispongono di token di accesso?

4

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?

    
posta Gregory Magarshak 11.06.2017 - 18:58
fonte

1 risposta

5

maybe this is to increase the security in case someone gets unauthorized access to the client app's symmetric secret.

Questa è una ragione valida, sì. L'invio di token di accesso di breve durata invece di segreti condivisi di lunga durata riduce la superficie di attacco.

Is there any other reason?

OAuth definisce diversi ruoli. Spesso una risorsa non risiede nello stesso server che gestisce l'autenticazione e / o l'autorizzazione. Un token di accesso può essere generato da un servizio ed essere consumato da un altro che in realtà non sa nulla di chi ha l'autorizzazione a cosa. Un server di risorse potrebbe non sapere quali utenti hanno accesso a quali risorse, ma ricevendo un token di accesso valido da un server di autorizzazione, può prendere una decisione sulla concessione dell'accesso.

Pensa al controllo degli accessi in un edificio (o al confine di un paese) - la guardia all'ingresso potrebbe non avere un elenco di ogni persona autorizzata all'interno e potrebbe non averti mai visto prima; ma se gli mostri una tessera di accesso valida per l'area riservata (o il passaporto nell'esempio di paese), saprà che dovrebbe farti entrare.

Questo ha anche alcuni aspetti negativi. Se l'accesso viene revocato, ma puoi conservare la tua carta di accesso, è probabile che entrerai ancora anche se non dovresti più. Questo può essere neutralizzato mettendo una data di scadenza sulla carta di accesso, e questo è il motivo per cui i token di accesso di solito sono di breve durata, quindi anche se vengono rubati, non possono essere utilizzati per molto tempo.

    
risposta data 11.06.2017 - 21:33
fonte

Leggi altre domande sui tag