Reindirizzamento lato client OAuth 2.0 anziché reindirizzamento HTTP

3

Sto implementando un server di autorizzazione OAuth 2.0 utilizzando il flusso del codice di autorizzazione (ad esempio, gli utenti autorizzeranno le app client a connettersi al nostro server). Il server di autenticazione è lo stesso del server di risorse e esegue Node.js. Il server delle risorse dispone di un'applicazione client esistente che gli utenti useranno per accedere e che è scritta in Angular e tutte le comunicazioni client-server sono su AJAX.

Questo pone un problema con il flusso standard che richiede un POST HTTP all'endpoint di autorizzazione che quindi reindirizza all'URL di reindirizzamento del client. Se faccio questo post su AJAX, il reindirizzamento andrà perso poiché una richiesta AJAX non può reindirizzare l'utente. Se, d'altra parte, lo faccio come un POST di un modulo, questo toglie l'utente dall'app Angular che li lascia in un posto strano se ci sono stati errori durante la richiesta (ad esempio il database è inattivo).

La mia soluzione è modificare l'endpoint di autorizzazione del server in modo che invece di restituire l'URL di reindirizzamento nell'intestazione HTTP Location , lo restituisca nel corpo della risposta. L'app Angolare può quindi accedere al valore e eseguire il reindirizzamento utilizzando window.location (supponendo che non vi siano errori).

La mia lettura (certamente incompleta) delle specifiche di OAuth 2 sembra suggerire che questo è permesso:

HTTP Redirections

This specification makes extensive use of HTTP redirections, in which the client or the authorization server directs the resource owner's user-agent to another destination. While the examples in this specification show the use of the HTTP 302 status code, any other method available via the user-agent to accomplish this redirection is allowed and is considered to be an implementation detail.

Vorrei capire quali sono le implicazioni di sicurezza di questo cambiamento, in particolare con riferimento a questo scambio .

    
posta Tamlyn 09.10.2015 - 18:05
fonte

1 risposta

1

La tua domanda è molto confusa in quanto non è chiaro chi sei veramente o pensi di essere ... Quindi, rivisitiamo il protocollo OAuth2.

I ruoli

OAuth defines four roles:

  • resource owner : An entity capable of granting access to a protected resource. When the resource owner is a person, it is referred to as an end-user.

  • resource server : The server hosting the protected resources, capable of accepting and responding to protected resource requests using access tokens.

  • client : An application making protected resource requests on behalf of the resource owner and with its authorization. The term "client" does not imply any particular implementation characteristics (e.g., whether the application executes on a server, a desktop, or other devices).

  • authorization server : The server issuing access tokens to the client after successfully authenticating the resource owner and obtaining authorization.

Se prendiamo lo stackoverflow come esempio, i ruoli sarebbero

  • proprietario della risorsa: kinda tu, ma più il tuo browser (stranamente)
  • client: stackoverflow
  • server delle risorse: facebook
  • server di autorizzazione: facebook

Chi sei?

Si inizia dicendo che si è il server delle risorse e quindi si dice che il server delle risorse utilizza il nodo e l'angolare.

I'm implementing an OAuth 2.0 resource server using the Authorization Code flow (i.e. users will authorise client apps to connect to our server). The resource server runs Node on the server and Angular on the client and all client-server communication is over AJAX.

Non ha senso. Il server delle risorse è fondamentalmente un servizio web chiamato da altre applicazioni, i client, al fine di recuperare le informazioni. Perché dovresti usare angularjs che è stato creato per creare un'applicazione web in un browser quando le cose che accederanno ad esso sono altre applicazioni che non hanno alcun concetto di browser.

Chi sei veramente?

Un'ipotesi casuale è che tu sia il server di autorizzazione o, più specificamente, riguardo alla tua domanda, il server di autorizzazione menzionato nella sezione 1.3.1 Codice di autorizzazione.

The authorization code is obtained by using an authorization server as an intermediary between the client and resource owner. Instead of requesting authorization directly from the resource owner, the client directs the resource owner to an authorization server (via its user-agent as defined in [RFC2616]), which in turn directs the resource owner back to the client with the authorization code.

Ora torna alla tua domanda ...

Sì, puoi farlo senza problemi. Più in particolare, il server di autorizzazione può restituire il comando di reindirizzamento al browser che quindi reindirizzerà alla pagina corretta utilizzando javascript. Non cambia nulla nel flusso, quindi non dovrebbe esserci alcun problema.

Dov'è la confusione allora?

È semplicemente che AJAX non funziona al posto del reindirizzamento, ma qui non è quello che stai facendo. Il flusso va così:

    Il client
  • reindirizza il browser al server di autorizzazione
  • server di autorizzazione reindirizza il browser al client

Un'idea comune non funzionante è che potresti sostituire quelli che reindirizzano una richiesta AJAX dal client javascript al server di autorizzazione e ottenere la tua autorizzazione. Non funziona a causa della stessa politica di origine e gli utenti non avrebbero la possibilità di confermare la concessione dell'autorizzazione. Ma non è il tuo caso, quindi scordiamoci.

Conclusione

Il javascript in una pagina è in realtà solo un'estensione del server (quando si utilizza https). L'unica differenza è che è una parte pubblica invece di una privata come il server. È una parte pubblica perché l'utente può vedere tutto il codice e tutti i dati. Puoi fare quasi tutta la tua logica nel codice javascript, che è ciò che stai facendo con angularjs.

Le uniche parti che non dovrebbero mai esserci sono le cose che l'utente non dovrebbe mai sapere. Ad esempio, il segreto del client è il motivo per cui è stato creato il flusso di concessione dell'autorizzazione implicita (1.3.2). Nel tuo caso, non elabori alcuna informazione che l'utente non dovrebbe mai sapere, quindi non ci sono problemi.

Riferimento: link

    
risposta data 15.10.2015 - 04:12
fonte

Leggi altre domande sui tag