OAuth2 Flusso implicito. Protezione aggiuntiva per access_token dall'intercettazione

Abbiamo un'applicazione JavaScript di una pagina che autentica l'utente sul nostro server usando il protocollo OAuth 2.0 (e il componente aggiuntivo AddId-Connect). Dopo l'autenticazione, il server invia un access_token all'applicazione. Supponiamo che access_token possa essere intercettato utilizzando scenari di attacco che non abbiamo tenuto in considerazione durante l'organizzazione del nostro sistema di sicurezza.

Tutti i nostri server utilizzano TLS e abbiamo due scenari di autenticazione:

1. Utente Internet:

1.1. L'utente fa clic sul pulsante Accedi nell'applicazione JS.

1.2 L'applicazione apre una finestra a comparsa Js-Applicion con l'URL generato "/ authorize" per il server di autenticazione.

1.3. Il server di autenticazione controlla i parametri nella richiesta in base alle specifiche e reindirizza l'utente alla pagina di accesso.

1.4 (può essere saltato se l'utente è stato autenticato sul server di autenticazione). L'utente fornisce credenziali e fa clic su "accesso".

1.5 Dopo il login riuscito, l'utente verrà reindirizzato a "redirect_uri" dal parametro di query, il token di accesso verrà impostato nel parametro Ottieni richiesta dopo #.

1.6. Dopo il reindirizzamento, l'applicazione legge il token di accesso da params e lo inserisce nell'archivio di sessione.

1.7. L'applicazione JS passerà questo token nell'intestazione Authenticate con ogni richiesta al server delle risorse.

1.8 Token di server di risorse valido senza ulteriori richieste al server di autenticazione.

2. Utente Intranet:

1.1. L'utente fa clic sul pulsante Accedi nell'applicazione JS.

1.2 L'applicazione apre un i-frame nascosto e carica il server di autenticazione del punto finale per l'autenticazione di Windows.

1.3 Il server di autenticazione verifica i parametri della richiesta in base alle specifiche.

1.4 * un po 'di magia qui con Windows auth e reindirizzamenti locali **

1.5 In caso di autenticazione riuscita, il server di autenticazione reindirizza l'utente all'indirizzo specificato nella richiesta Get e specifica i parametri della richiesta access_token.

1.6. Dopo il reindirizzamento, l'applicazione legge il token di accesso da params e lo inserisce nell'archivio di sessione.

1.7. L'applicazione JS invierà questo token nell'intestazione Authenticate con ogni richiesta al server delle risorse.

1.8 Token di server di risorse valido senza ulteriori richieste al server di autenticazione.

Reindirizza esempio uri: https://localhost:44300/popup-callback.html#id_token=NWrvGKVPTnw_shorted&access_token=eyJhbGciOiJSUzI_shorted&token_type=Bearer&expires_in=3600&scope=openid%20profile%20api1&state=46c8484e5e1b4a1f8bd182891efd7180

Domande:

1. C'è un modo per associare un token a un utente specifico in modo che sia protetto dall'intercettazione?

2. Se aggiungiamo il binding di access_token all'indirizzo IP dell'utente, questo complicherà il problema all'attaccante e in che modo ciò influirà sulla sicurezza del sistema?