Accesso al flusso implicito da SPA

1

Esaminare il flusso implicito per accedere con link e link . Il processo inizia con l'inoltro a una pagina di accesso lato server.

Sono consapevole che ci sono dei vantaggi nel non dover apportare modifiche alla SPA se vengono utilizzati provider aggiuntivi, ma ci sono altri motivi per cui sei incoraggiato a utilizzare una pagina di accesso lato server? Sembra che l'implicazione sia che è più sicuro, ma non capisco perché.

    
posta ChrisFletcher 04.04.2018 - 19:17
fonte

1 risposta

2

Presumo che tu ti stia riferendo a un flusso implicito di OAuth 2.0 .

Penso che ti stia chiedendo il motivo per cui devi allontanarti dalla SPA per consentire all'utente di autorizzare la tua app (effettuando il login e di solito selezionando le autorizzazioni per concedere la tua applicazione).

OAuth, come protocollo, è progettato per consentire a una terza parte di autenticare l'identità di un utente. Per utilizzare Google OAuth come esempio, l'utente lascia il tuo sito e accede a Google, in modo che tu non possa rubare la password o eseguire altre azioni per conto dell'utente. Hanno lasciato il tuo sito e sono entrati nel sito del loro provider di identità attendibile, a cui ti stai fidando implicitamente consentendo loro di autenticare l'identità dell'utente.

Se si esegue l'autenticazione con il proprio server, potrebbe non essere necessario utilizzare il protocollo OAuth. Consentitegli semplicemente di inviare il loro nome utente e password direttamente. Si stanno già affidando a te per gestire il loro nome utente e password iscrivendoti al tuo servizio.

Le uniche buone ragioni per cui sono consapevole di utilizzare il tuo provider OAuth sul tuo sito sono:

  • Centralizzazione dell'identità in un'architettura di micro-servizi
  • Esposizione di un provider di identità per le terze parti da utilizzare
  • Utilizzo di una soluzione software preconfezionata come provider di identità, quindi non è necessario eseguire il rollover della propria soluzione di identità e autenticazione

Modifica: ecco una risorsa migliore sul flusso implicito. RFC 6749 Sezione 4.2

Ed ecco un diagramma ascii di come funziona il flusso implicito. Si noti che il server di autorizzazione è distintamente un'entità separata in questo diagramma e che il passo di autenticazione è diretto verso questo server.

 +----------+
 | Resource |
 |  Owner   |
 |          |
 +----------+
      ^
      |
     (B)
 +----|-----+          Client Identifier     +---------------+
 |         -+----(A)-- & Redirection URI --->|               |
 |  User-   |                                | Authorization |
 |  Agent  -|----(B)-- User authenticates -->|     Server    |
 |          |                                |               |
 |          |<---(C)--- Redirection URI ----<|               |
 |          |          with Access Token     +---------------+
 |          |            in Fragment
 |          |                                +---------------+
 |          |----(D)--- Redirection URI ---->|   Web-Hosted  |
 |          |          without Fragment      |     Client    |
 |          |                                |    Resource   |
 |     (F)  |<---(E)------- Script ---------<|               |
 |          |                                +---------------+
 +-|--------+
   |    |
  (A)  (G) Access Token
   |    |
   ^    v
 +---------+
 |         |
 |  Client |
 |         |
 +---------+
    
risposta data 05.04.2018 - 06:05
fonte

Leggi altre domande sui tag