OAuth 2.0 client reindirizza la sicurezza degli endpoint

1

Questa domanda riguarda la protezione dell'endpoint di reindirizzamento sul lato client alla fine di un flusso di "codice di autorizzazione".

Abbiamo progettato un server back-end che gestisce il processo di autorizzazione di OAuth 2.0 con diversi server di autorizzazione: la nostra applicazione lato server è un client di più provider OAuth 2.0. Chiamiamolo gestore autorizzazioni .

Il processo di autorizzazione può essere avviato da varie app (mobile, sito, ecc.), ma vogliamo che gestore autorizzazioni gestisca tutte le credenziali e la logica di OAuth 2.0 (come ottenere un token, ecc.) . Le applicazioni "chiedono" al gestore autorizzazioni dove reindirizzare il client e gestore autorizzazioni crea un URL di richiesta di autorizzazione con il suo clientId, redirectURI, ecc. L'applicazione deve solo apri l'URL in una nuova finestra frame / browser e non preoccuparti di gestire il resto del processo.

Poiché il gestore autorizzazioni non avvia il flusso di autorizzazione (il browser dell'utente non lo raggiunge per primo), non ha autenticato l'utente, quindi non ha alcuna prova di "autenticazione utente" quando il l'utente raggiunge il suo redirectURI, solo lo stato e il codice.

È necessario che il nostro endpoint di reindirizzamento richieda l'autenticazione dell'utente? Dovremmo aver bisogno che l'utente sia pre-autenticato quando viene reindirizzato al nostro URI di reindirizzamento (come un cookie di sessione)?

Dal mio punto di vista, lo stato + il codice di autorizzazione crea una superficie di attacco veramente piccola:

  • entrambi sono stringhe generate casualmente
  • entrambi hanno una durata molto breve
  • uno è generato dal client (stato), l'altro dal server di autorizzazione (codice). Un utente malintenzionato dovrebbe "crackare" entrambi i generatori
  • Il codice di autorizzazione è convalidato dal server di autorizzazione quando si effettua una richiesta di token
  • anche se un utente malintenzionato ha violato entrambi, attiva solo una richiesta di token di accesso valida dal back-end al back-end, ma il nostro endpoint di reindirizzamento non offre alcuna informazione in cambio.
posta Michael Tecourt 27.11.2015 - 09:53
fonte

0 risposte

Leggi altre domande sui tag