Rinnova il token di accesso per la concessione implicita OAuth2

Question

Rinnova il token di accesso per la concessione implicita OAuth2

#1 da (2 voti)
#2 da (1 voti)

3

Vogliamo utilizzare la sovvenzione implicita di OAuth2 come viene proposta per le applicazioni a pagina singola. Per le applicazioni JavaScript che non hanno una classica sessione Web. Le applicazioni hanno solo token di accesso che scadono dopo un'ora. Utilizziamo un servizio di autenticazione centrale (CAS) in cui l'utente può inserire una sessione.

All'inizio l'utente non ha alcuna sessione. Quando l'utente avvia l'applicazione JS, sposta l'agente utente nel CAS dove viene autenticato tramite le sue credenziali. Dopo l'autenticazione riuscita verrà reindirizzato all'applicazione JS con il token di accesso nel frammento.

Dopo poco tempo il token di accesso non è più valido e l'applicazione necessita di un nuovo token di accesso. Per questo l'applicazione sposta nuovamente l'agente utente sul CAS. Le domande sono: cosa dovrebbe fare il CAS?

L'utente ha già una sessione nel CAS. È consentito utilizzare questa sessione per autenticare l'utente? In questo caso l'utente non deve fornire nuovamente le sue credenziali.
Il servizio di autenticazione centrale potrebbe chiedere nuovamente le credenziali dell'utente.

A mio parere chiedere all'utente le sue credenziali una volta ogni ora è un po 'strano, quindi preferirei la prima soluzione. Ma sarebbe un modo valido per ottenere un nuovo token di accesso per quanto riguarda l'RFC OAuth2?

La RFC afferma " The implicit grant [...] relies on the presence of the resource owner ". Penso che la prima soluzione non si basa sulla presenza del proprietario della risorsa. Ad esempio, il proprietario della risorsa potrebbe lasciare il computer per alcune ore ma l'applicatino JS è ancora in esecuzione. Se un token di accesso diventa non valido, l'applicazione JS può ottenere un nuovo token di accesso semplicemente navigando verso il CAS che si autentica automaticamente tramite la sessione e reindirizza nuovamente all'applicazione JS. Questo viene fatto automaticamente senza la presenza del proprietario della risorsa.

Il CAS poteva solo essere sicuro che il proprietario della risorsa fosse presente se chiedesse nuovamente le credenziali. Ma ciò significherebbe chiedere le credenziali ogni 30 minuti.

Se queste opzioni non si applicano, come si può realizzare il passaggio (B) nella Figura 4 in 4.2 della RFC6749 per rinnovare i token di accesso?

authentication oauth authorization session-management single-page-app

posta DanielE 09.08.2016 - 11:40

fonte

2 risposte

Leggi altre domande sui tag authentication oauth authorization session-management single-page-app

Backup della password Attacca WEP / WPA / WPA2

score 2 · Answer 1

Se controlli il CAS, è compito dell'utente accedere a un nuovo token di accesso.

Poiché il tuo utente ha già autorizzato la SPA utilizzando il tuo CAS, se la sessione è ancora valida con il CAS non è necessario chiedere loro di eseguire nuovamente l'autenticazione usando le loro credenziali.

Naturalmente, è il tuo livello di rischio accettabile per quanto a lungo dovrebbero rimanere autenticati al CAS. Se si tratta di un'applicazione di sicurezza elevata, è possibile che si desideri ridurre il timeout della sessione o chiedersi perché la scadenza del token di accesso è stata impostata per scadere prima del timeout della sessione CAS.

Risposta originale:

~~Dai un'occhiata alla sezione Aggiorna token .~~

La sessione che è valida nel CAS dovrebbe significare che l'agente utente ha un token di aggiornamento valido: questo è ciò che è necessario per rinnovare il token di accesso per l'utente.

Refresh tokens are credentials used to obtain access tokens. Refresh tokens are issued to the client by the authorization server and are
used to obtain a new access token when the current access token
becomes invalid or expires

Correzione: I token di aggiornamento non devono essere emessi per sovvenzioni implicite .

The authorization server MUST NOT issue a refresh token.

La "presenza" del proprietario della risorsa è invocata solo per l'autorizzazione iniziale.

score 1 · Answer 2

Penso che la sezione pertinente della specifica (sezione 4.2.1) sia questa:

If the request is valid, the authorization server authenticates the
resource owner and obtains an authorization decision (by asking the
resource owner or by establishing approval via other means).

Per autenticare un utente, ti viene offerta l'opzione "Chiedere al proprietario della risorsa" o "Stabilire con altri mezzi". Il primo di solito significa credenziali di accesso. Quest'ultimo può significare qualsiasi cosa, da ssh auth, ai cookie, al richiamo del numero di telefono dell'utente e chiedendo loro di fornire un esempio di voiceprint cantando Barnes & "Fish Heads" di Barnes.

In breve: usare la sessione su CAS va bene, e bene all'interno della specifica.