OAuth2 Flusso implicito: possibili vettori di attacco del token di aggiornamento tramite CORS?

Question

OAuth2 Flusso implicito: possibili vettori di attacco del token di aggiornamento tramite CORS?

#1 da (2 voti)

3

Attualmente stiamo implementando un'applicazione a singola pagina (Angular2) e quindi abbiamo incontrato lo standard "come possiamo proteggere il nostro problema dell'API backend".

La soluzione standard a questo sembra utilizzare il flusso di Grant implicito OAuth2, che è tutto a posto. Stiamo implementando un server di autorizzazione personalizzato che si autentica utilizzando la nostra soluzione SSO Web (Apri AM / SAML), controlla le licenze e rilascia i token di accesso tramite il gateway API (Mashape Kong).

Il token di accesso è (come specificato nel flusso implicito di OAuth2) restituito allo SPA utilizzando un reindirizzamento, fornendo il token di accesso nel frammento ( https://my.spa.com/#access_token=asdfasdf&token_type=bearer&expires_in=1800 ).

Finora, niente specialità. Ora: il token di accesso è valido solo per un breve periodo di tempo e non vi è alcun token di aggiornamento; non vogliamo che l'utente finale venga effettivamente reindirizzato nuovamente al server di autorizzazione (apparirebbe sfavorevole / sfarfallio / ...). La nostra idea era di utilizzare la sessione esistente con il server di autorizzazione (che abbiamo implementato, vedi sopra) per aggiornare il token di accesso (creane uno nuovo) tramite una chiamata CORS a un punto finale speciale del server di autorizzazione (chiamiamolo /heartbeat ).

Ovviamente, questo richiede un paio di cose da fare:

Il Origin deve essere esattamente l'host dell'applicazione chiamante e il server di autenticazione deve verificare e riflettere quello nella risposta di preflight
L'applicazione client deve eseguire la chiamata CORS con withCredentials: true attivata (utilizzando XMLHttpRequest , credentials: include per Fetch)

Abbiamo eseguito un'implementazione di questo test, e sembra funzionare abbastanza bene, ma voglio comunque chiedere a voi come esperti su questo: Ci sono (addizionali) vettori di attacco quando abilitate questo tipo di aggiornamento? Oltre ai soliti sospetti per la concessione implicita, cioè.

Cordiali saluti, Martin

api javascript oauth2 cors api-gateway

posta donmartin 01.12.2016 - 16:34

fonte

1 risposta

Leggi altre domande sui tag api javascript oauth2 cors api-gateway

Dare un senso ai numeri di John The Ripper Proving di azzeramento

score 2 · Accepted Answer

Invece di seguire un approccio completamente diverso che, come accennato, meriterebbe una revisione più approfondita dal punto di vista della sicurezza, suggerirei di sfruttare ciò che è già specificato in OpenID Connect: il supporto di una modalità di autenticazione immediata attraverso l'uso di prompt=none .

While SPAs cannot use refresh tokens, they can take advantage of other mechanics that provide the same function. A workaround to improve user experience is to use prompt=none when you invoke the /authorize endpoint. This will not display the login dialog or the consent dialog. In addition to that if you call /authorize from a hidden iframe and extract the new access token from the parent frame, then the user will not see the redirects happening.

(fonte: Auth0 - Quale flusso OAuth 2.0 dovrei usare? ; l'enfasi è mia)

Il tuo server di autorizzazione dovrà supportare questo parametro di richiesta aggiuntiva e supportare anche l'approvazione automatica per richieste / ambiti che erano già stati autorizzati dall'utente.

Il vantaggio principale di questo approccio è che sta sfruttando la maggior parte di ciò che già esisteva, quindi non aumenta in modo significativo la superficie di attacco come sarebbe il caso di un approccio completamente nuovo e diverso.

Controlla la libreria Auth0.js per un'implementazione di riferimento su come questo tipo di autenticazione silenziosa potrebbe essere realizzato.