Flusso implicito Oauth2 con token di accesso per l'aggiornamento di una sola pagina

Question

Utilizzo Thinktecture AuthorizationServer (AS) e funziona perfettamente.

Mi piacerebbe scrivere un'applicazione nativa per javascript singola che può chiamare direttamente WebAPI, tuttavia il flusso implicito non fornisce un token di aggiornamento.

Se viene effettuata una chiamata AJAX, se il token è scaduto, l'API invierà un reindirizzamento alla pagina di accesso, poiché i dati utilizzano popup dinamici, ciò interromperà l'utente.

Come fa Facebook o StackOverflow a fare questo e consente ancora il javascript in esecuzione sulla pagina per chiamare le API?

Soluzione proposta

Ha lo scenario di seguito suono sensibile (supponendo che questo può essere fatto con iframe):

mio SPA mi indirizza alla AS e io ottenere un token dal flusso implicito. All'interno di AS, fare clic su Consenti ambito Read data e fare clic su Remember decision, quindi su Allow.

Dal momento che ho fatto clic sul pulsante Remember decision, ogni volta che prendo AS per un token, un nuovo token viene automaticamente restituito senza che sia necessario accedere (posso vedere il cookie FedAuth che sta ricordando la mia decisione e credo che questo lo renda possibile solo lavoro).

Con la mia SPA (app non affidabile), non ho un token di aggiornamento solo un token di accesso. Così, invece ho:

1. facilitare l'utilizzo si è connesso e cliccato ricordare decisione (altrimenti iframe non funzionerà)
2. chiamata WebAPI, se 401 risposta cercare di ottenere un nuovo token dalle istruzioni riportate di seguito ...
3. Avere un iframe nascosto nella pagina, che imposterò l'URL per ottenere un nuovo token di accesso dal server di autorizzazione.
4. Ottieni il nuovo token dal frammento di hash dell'iframe, quindi memorizzalo nella SPA e utilizzalo per tutte le future richieste WebAPI.

Immagino che sarei ancora nei guai se il cookie FedAuth viene rubato.

Qualsiasi modo standard o consigliato per lo scenario sopra descritto?

Answer 1

In Google o-Auth, il token di accesso sarà valido solo per 1 ora, quindi è necessario aggiornare il token di accesso in ogni ora, in modo semplice è possibile creare Web API per farlo, è necessario disporre di un Aggiorna token, e anche quel token di aggiornamento non sarà scaduto, usando il codice C#, l'ho fatto.

if (dateTimeDiff > 55) 
      { 
       var request = (HttpWebRequest)WebRequest.Create("https://www.googleapis.com/oauth2/v3/token"); 
       var postData = "refresh_token=your refresh token"; 
       postData += "&client_id=your client id"; 
       postData += "&client_secret=your client secrent"; 
       postData += "&grant_type=refresh_token"; 

       var data = Encoding.ASCII.GetBytes(postData);    
       request.Method = "POST"; 
       request.ContentType = "application/x-www-form-urlencoded"; 
       request.ContentLength = data.Length; 
       request.UseDefaultCredentials = true; 

       using (var stream = request.GetRequestStream()) 
       { 
        stream.Write(data, 0, data.Length); 
       } 
       var response = (HttpWebResponse)request.GetResponse(); 
       string responseString = new StreamReader(response.GetResponseStream()).ReadToEnd(); 

      } 

è necessario salvare l'ultima volta che la data aggiornata del token di accesso da qualche parte (diciamo nel database), in modo che, ogni volta che si deve fare una richiesta, in modo da poter sottrarre che con il tempo la data corrente, se è più di 60 minuti, è necessario chiamare il webapi per ottenere un nuovo token.

Answer 2

Non sono sicuro se ho capito la tua domanda, ma,

Vorrei scrivere un javascript un'applicazione singola pagina nativa che può chiamare un WebAPI direttamente, tuttavia il flusso implicita non fornisce un token di aggiornamento.

sintesi dei fatti,

token di aggiornamento è talvolta usato per essere una parte di A: Autorizzazione Concessione

https://tools.ietf.org/html/rfc6749#section-1.5

e come hai detto in flusso implicita tu non tornare aggiornamento token, ma solo nella parte Concessione autorizzazioni

https://tools.ietf.org/html/rfc6749#section-4.2.2

in modo da poter tornare token di aggiornamento per il rilascio di token di accesso (aggiornamento gettoni sono sempre opzionali)

https://tools.ietf.org/html/rfc6749#section-5.1

Con la mia SPA (non attendibile app), non ho un aggiornamento token solo un token di accesso . Così, invece ho:

1) Assicurarsi utente si è connesso e cliccato ricordare decisione (altrimenti iframe non funzionerà)

2) Chiamare WebAPI, se 401 risposta cercare di ottenere un nuovo token i passi sotto. ..

3) Avere un iframe nascosto nella pagina, che imposterò l'URL per ottenere un nuovo token di accesso dal server di autorizzazione .

4) Ottenere il nuovo token dal frammento di hash dell'iframe, quindi lo memorizzarlo nella SPA e utilizzarlo per tutte le future richieste WebAPI.

1) SPA (tu) non ha idea se l'utente selezionato ricorda la decisione. È nella direzione AS e dovrebbe essere completo blackbox. Salta questo passaggio.

2) È possibile provare a utilizzare il token di accesso e attendere il risultato, sempre.

3) Se il token di accesso è scaduto e non si dispone di token di aggiornamento, è ancora possibile creare iframe nascosti e provare a ottenere un nuovo token di accesso.

4) Supponiamo che l'AS fornisca l'opzione per ricordare la decisione e non lo cambi in futuro, quindi: l'iframe otterrà un nuovo token di accesso senza interazione dell'utente, quindi i risultati torneranno in un limite di tempo sconosciuto. Il risultato può essere verificato con setInterval per cookie specifici di lettura o iframe postmessage. Se non ottenere indietro i dati nel limite di tempo, poi uno da scenari seguenti si è verificato:

• lag, come è lento, la connessione è lenta o limite di tempo è troppo stretto
• utente non ha ancora selezionare Memorizza decisione

In questo caso:

5) mostrano iframe con login

ritengo scenario di cui sopra, come buona pratica se AS doesnt fornire i token di aggiornamento, ma suppongo anche che ogni AS non prenda in considerazione l'opzione.

StackOverflow < ---> Google scenario (posso solo immaginare)

1) Accesso utente, richiesta di autorizzazione è verificato

log 2) l'utente in, diventa così token di accesso

3) cerca così di utilizzare token di accesso

4) diventa così indietro risultato + token di aggiornamento

5) salva SO token di aggiornamento

6) ha così accesso permanente per gli utenti account Google

Answer 3

Mi rendo conto che il problema è che l'utente sperimenterà un'interruzione quando il token di accesso è scaduto, da un reindirizzamento al pagina di accesso del server di autorizzazione. Ma non penso che tu possa e debba aggirare questo, almeno, quando usi la concessione implicita.

Come già saprete, lo implicit grant deve essere utilizzato dai consumatori che NON possono mantenere segrete le proprie credenziali. Per questo motivo, il token di accesso emesso da un server di autorizzazione dovrebbe avere un ttl limitato. Ad esempio, Google invalida il proprio token di accesso in 3600 sec. Ovviamente puoi aumentare il TTL, ma non dovrebbe mai diventare un token longevo.

Un'altra cosa da notare è che, a mio parere, l'interruzione utente è minima, cioè se implementata correttamente, l'utente dovrà solo autenticarsi una volta con il server di autorizzazione. Dopo averlo fatto (ad esempio la prima volta quando si autorizza l'accesso dell'applicazione a tutte le risorse che l'utente controlla) verrà stabilita una sessione (basata su cookie o token) e quando il token di accesso del consumatore (app Web che utilizza la concessione implicita) scade, l'utente verrà informato che il token è scaduto e che è richiesta la re-autenticazione con il server di autorizzazione. Ma poiché una sessione è già stata stabilita, l'utente verrà immediatamente reindirizzato all'app Web.

Se tuttavia questo non è ciò che si desidera, si dovrebbe, a mio parere, considerare l'utilizzo della concessione del codice di autorizzazione, invece di fare cose complicate con iframe. In tal caso è necessaria un'applicazione web lato server perché in questo modo è possibile mantenere segrete le credenziali e utilizzare i token di aggiornamento.

Answer 4

Sembra che sia necessario accodare le richieste nel caso in cui un token di accesso scada. Questo è più o meno come Facebook e Google lo fanno. Un modo semplice utilizzando Angular sarebbe aggiungere un intercettore HTTP e verificare le risposte HTTP401. Se ne viene restituito uno, si autentica nuovamente e si accodano le richieste che arrivano dopo che la richiesta di autenticazione è stata completata (ad es.una promessa). Fatto ciò, è possibile elaborare la coda in sospeso con il token di accesso appena restituito dalla richiesta di autenticazione utilizzando il token di aggiornamento.

Happy Coding.