OpenID Connect: perché utilizzare il flusso del codice di autorizzazione?

3

Ho una domanda sull'implementazione di OpenID Connect Speravo di poter ricevere aiuto. Comprendo i diversi flussi e ottenendo che il flusso del codice di autorizzazione sia buono perché consente alle credenziali del client e alla comunicazione da server a server più sicuro della comunicazione tramite l'agente utente. Ma anche così l'uso del codice intermedio sembra non necessario se il client e l'OP dovessero utilizzare la crittografia autenticata sulla loro corrispondenza attraverso l'agente utente. Gli attacchi Groundhog Day possono essere limitati mediante l'uso di un tempo di scadenza molto breve specificato nel messaggio o eliminato con una richiesta preliminare all'OP per un nonce. Supponendo una crittografia sufficientemente strong, ad esempio AES-256, penserei che anche i token di aggiornamento possano essere inviati tramite l'agente utente con una diminuzione trascurabile della sicurezza. Ci sono altre considerazioni o ragioni per cui questo potrebbe / non dovrebbe essere fatto che potrei aver ignorato?

    
posta k0mrade_kangaroo 25.03.2015 - 13:08
fonte

3 risposte

1

Anche se la connessione tra l'agente utente ei server sono sicuri, l'agente utente potrebbe non essere completamente protetto. Poiché il flusso del codice di autorizzazione garantisce che l'agente utente non sia al corrente dei token, la sicurezza viene migliorata riducendo l'esposizione di token tra solo i server.

    
risposta data 28.06.2016 - 03:14
fonte
1

C'è un ulteriore livello di sicurezza. Quando viene effettuata una richiesta all'endpoint Token per scambiare il codice ricevuto dall'endpoint Autorizza, consente all'applicazione client di autenticarsi sul server delle autorizzazioni. Quando si effettua una richiesta all'endpoint Token, si inviano più dati sul client. Per i clienti riservati (applicazioni che sono in grado di memorizzare in modo sicuro un client segreto) l'endpoint del token richiede al client di autenticarsi tramite un ID client e un segreto client. Vedere questa sezione della 2.0 spec e questa sezione del OpenID Connect spec . Per riassumere, l'applicazione client può inviare l'ID client e il segreto del client in due modi. Un modo è utilizzare la coppia come combinazione nome utente / password tramite l'autenticazione HTTP Basic e l'altra inviando le credenziali nel corpo POST della richiesta dell'endpoint Token. Devo aggiungere che sono richiesti solo i tipi di client confidenziali per inviare la coppia di client id / client secret. I tipi di client pubblici in genere non chiamano l'endpoint token *** Ad esempio, il flusso implicito utilizza solo l'endpoint Authorize. Uno dei motivi per cui il flusso implicito è considerato meno sicuro è perché l'applicazione client non si autentica mai con il server di autorizzazione. Il flusso implicito invia solo un ID client ed è verso l'endpoint Authorize che non supporta un client secret o in alcun modo che il client possa autenticarsi. Si noti che l'invio dell'ID client non sta effettuando l'autenticazione del client. Lo sta solo identificando.

La linea di fondo: quando usi il flusso del codice di autorizzazione stai autenticando il tuo cliente e quindi aggiungi un altro livello di sicurezza.

*** È possibile eseguire uno scenario in cui un client pubblico utilizza l'endpoint token. Se si dispone di un'applicazione JavaScript che utilizza il flusso di proprietario delle risorse e sta inviando le credenziali direttamente al punto finale Token che non avrebbe inviare un segreto client perché un segreto client non può essere memorizzati in modo sicuro in un'applicazione JavaScript.

    
risposta data 25.11.2017 - 12:40
fonte
0

Nella concessione implicita, che sembra essere in considerazione, i token vengono restituiti dall'endpoint di autorizzazione nell'URL di reindirizzamento e verranno registrati nella cronologia del browser.

La concessione del codice di autorizzazione è vantaggiosa per i client pubblici (oltre il flusso implicito) perché i token sono ottenuti tramite una richiesta POST a l'endpoint del token . La concessione consente anche di utilizzare PKCE .

Per i token dei clienti riservati possono viaggiare su back-channel sicuro e non devono essere esposti all'agente utente nel flusso del codice di autorizzazione.

    
risposta data 28.09.2018 - 09:21
fonte