Più OAuth2 access_tokens sulla stessa pagina

Question

Più OAuth2 access_tokens sulla stessa pagina

#1 da (2 voti)

4

Ci è stato affidato il compito di implementare una dashboard contenente più widget. La dashboard stessa e tutti i widget devono accedere a varie API protette. Il nostro protocollo di autorizzazione è OpenID.

Attualmente, la dashboard richiede un access_token con tutti i scope s richiesti da tutti i widget. I widget utilizzano questo access_token condiviso per effettuare richieste per proteggere le API.

Il problema è che, poiché questo access_token condiviso ha così tanti ambiti, è troppo "potente". Siamo preoccupati che utilizzando questo token condiviso, i widget e le API possano avere più diritti di quelli a cui hanno diritto. Idealmente vorremmo che ogni widget avesse un access_token separato con il proprio scope .

Non sono sicuro di come ottenere ciò. Se ogni widget richiede il proprio access_token , l'utente verrà reindirizzato all'endpoint di autorizzazione più volte. Questo è inaccettabile per motivi di UX.

Abbiamo preso in considerazione il wrapping dei widget in iframe s. Così ogni widget può reindirizzare all'interno del proprio frame senza influenzare il dashboard. Tuttavia, poiché vengono eseguiti tutti nello stesso dominio, possono sempre accedere a access_token s di altri widget (perché sono memorizzati in LocalStorage ), quindi non sono sicuro che sia meglio dal punto di vista della sicurezza.

Come possiamo architettare il sistema di autorizzazione in una dashboard in modo che tutti i widget abbiano il loro access_token s?

architecture openid oauth2

posta Oleg 30.10.2017 - 11:53

fonte

1 risposta

Leggi altre domande sui tag architecture openid oauth2

Versioning API: livello di rilascio vs livello funzionale Stringa di coesione di classe stretta, tutti o solo metodi pubblici?

score 2 · Answer 1

Da una prospettiva di modellazione delle minacce, non è chiaro quale vantaggio di sicurezza otterrai se ogni widget ha il proprio token.

Quindi, a meno che non si possa dimostrare che esiste un chiaro vantaggio in termini di sicurezza (anche se la difesa è approfondita), il mio suggerimento sarebbe di evitare l'aggiunta di complessità nell'applicazione e di mantenerla semplice. Molti problemi di sicurezza sono causati dalla complessità.

Per il caso che presenti, esaminiamo le possibilità.

Se il client è compromesso, (ovvero, client in linguaggio OAuth 2.0 come per RFC 6749 ) non importa se ogni widget ha un diverso token o meno, tutti saranno compromessi. Allo stesso modo, se il server di autorizzazione o il server di risorse viene compromesso, non è utile avere di nuovo un token diverso per widget.
Se dovessi avere un token separato per ogni widget, il modello giusto sarebbe quello di averli come client diversi con ciascuno dei propri ambiti approvati che possono richiedere dal server di autorizzazione. Ciò garantirà almeno che un widget non possa richiedere un token con ambiti per i quali non è stato approvato nelle richieste al server delle risorse.

Tuttavia, in base alla tua spiegazione, questa non sembra essere la preoccupazione principale. (L'unica preoccupazione che si ha è che un singolo token di accesso con troppi ambiti sia condiviso da tutti i widget.) Anche se lo fosse, si vorrebbe pesare contro l'usabilità perché una cattiva usabilità induce gli utenti a prendere scorciatoie che si vorrebbe evitare .

Quindi, sulla base di questi punti, direi che non sembra essere una preoccupazione per la sicurezza principale (a meno che mi manchi qualcosa). Se fossi al tuo posto, potrei anche essere felice di ottenere un token di accesso per l'intera dashboard e utilizzarlo quando necessario.

Per tua informazione, puoi consultare RFC 6819: Considerazioni sulla sicurezza e sulla modellazione delle minacce OAuth 2.0 . Non penso che abbia qualcosa di simile a questo.