Non ti stai preoccupando delle cose giuste
Protezione delle informazioni che si trovano sul client?
Non devi fare nulla una volta che le informazioni hanno raggiunto il tuo cliente (es .: il tuo browser) per proteggerlo. È possibile archiviare il token di accesso in un cookie, in un campo nascosto della pagina Web, nella cache locale html5 o semplicemente visibile direttamente nel mezzo della pagina e non cambia nulla (eccetto lo spallamento ...).
Preoccuparsi del token di accesso una volta che è sul client è come aprire il blocco note per scrivere la password e-mail e quindi preoccuparsi che un utente malintenzionato sia in grado di rubare tali informazioni da una posizione remota. Non succede A meno che il tuo computer non sia già compromesso, ma a questo punto l'hai già perso.
Dove ha senso preoccuparsi?
Di solito, le tue informazioni sono vulnerabili quando sono in transito. Nel caso di OAuth2 (flusso implicito), il token di accesso sarà in transito in due punti:
- dal server di autorizzazione al browser
- dal tuo browser al server delle risorse
Proteggere le informazioni mentre è in transito è facile come usare TLS ovunque. Che dovresti già fare visto che stai usando OAuth2 ed è richiesto dal protocollo.
Ora il vero problema
Il modo in cui intendi utilizzare OAuth2 non è probabilmente il modo in cui dovresti utilizzarlo.
Per capire perché probabilmente utilizzerai in modo improprio OAuth2, devi conoscere i flussi. OAuth2 definisce il flusso di autorizzazione 4
- Codice di autorizzazione (solo buono ma ... continua a leggere)
- Implicito (falso senso di sicurezza)
- Credenziali password proprietario risorse (idea orribile)
- Credenziali client (non applicabile al tuo caso)
Poiché utilizzi un client javascript, l'unico flusso che funziona per te è il flusso implicito e ora inizia i problemi.
Problemi di flusso implicito
Ce ne sono molti ma parliamo solo di quello più critico. Il token di accesso non è associato a un client specifico! dalla sezione delle specifiche 10.16:
For public clients using implicit flows, this specification does not
provide any method for the client to determine what client an access
token was issued to.
Questo apre le porte all'aggressore per impersonare te, il proprietario della risorsa, e quindi ottenere l'accesso al server delle risorse. Continuiamo a leggere la sezione 10.16:
A resource owner may willingly delegate access to a resource by
granting an access token to an attacker's malicious client. This may
be due to phishing or some other pretext. An attacker may also steal
a token via some other mechanism. An attacker may then attempt to
impersonate the resource owner by providing the access token to a
legitimate public client.
In the implicit flow (response_type=token), the attacker can easily
switch the token in the response from the authorization server,
replacing the real access token with the one previously issued to the
attacker.
Servers communicating with native applications that rely on being
passed an access token in the back channel to identify the user of the
client may be similarly compromised by an attacker creating a
compromised application that can inject arbitrary stolen access
tokens.
Any public client that makes the assumption that only the resource
owner can present it with a valid access token for the resource is
vulnerable to this type of attack.
Il primo attacco in realtà non è nemmeno un attacco ma piuttosto solo un "difetto" nel flusso implicito ...
Il prossimo attacco
Ora inizia i grandi problemi. Sembra che tu stia cercando di utilizzare il flusso implicito di OAuth2 come forma di autenticazione delegata dell'utente finale che non è stata pensata per fornire. Torna alla sezione delle specifiche 10.16
Authenticating resource owners to clients is out of scope for this
specification. Any specification that uses the authorization process
as a form of delegated end-user authentication to the client (e.g.,
third-party sign-in service) MUST NOT use the implicit flow without
additional security mechanisms that would enable the client to
determine if the access token was issued for its use (e.g.,
audience-restricting the access token).
A questo punto è quasi tutto per te.
Come si installa quell'attacco?
È piuttosto semplice. Supponiamo che il tuo servizio REST abbia richiesto un token di accesso da Facebook. Tutto ciò che un utente malintenzionato deve fare è ospitare un servizio, ad esempio StackOverflow, e richiedere un token di accesso da Facebook. Quando offri il token di accesso di Facebook a StackOverflow, StackOverflow (il nostro aggressore) può ora impersonare te con il tuo servizio REST.
Tutto ciò perché i token di accesso non sono associati a un client specifico.
Una soluzione
Non utilizzare il flusso implicito e utilizzare invece il flusso del codice di autorizzazione. Ciò significa che la tua app 100% lato client non dovrà più essere un'app 100% lato client.
Perché non stai utilizzando il server che serve il client angularjs all'utente per gestire il flusso OAuth2?
Riferimento: link