Qual è la necessità del tipo di concessione "password" in OAuth 2.0?

1

Il bisogno di OAuth è sorto perché volevamo dare accesso ad alcune delle nostre risorse al Resource Server (ad esempio, il mio nome / email su Facebook) alle app di terze parti. Questo giustifica vari tipi di sovvenzioni.

Ma per il tipo di concessione "password", la specifica dice che questo tipo è adatto nei casi dove il proprietario della risorsa ha una relazione di fiducia con il cliente.

La mia domanda è: quale è la necessità di aggiungere ulteriori complicazioni se possiamo gestire l'app di fiducia con nome utente / password?

L'unica cosa rilevante che riesco a trovare nelle specifiche è:

It is also used to migrate existing clients using direct authentication schemes such as HTTP Basic or Digest authentication to OAuth by converting the stored credentials to an access token.

Se questo è l'unico motivo, come potrei essere interessato se utilizzo l'autenticazione diretta con "app di fiducia"?

    
posta Akeshwar Jha 26.04.2017 - 21:06
fonte

1 risposta

1

La prima cosa è che dovremmo cercare di evitare il più possibile il tipo di concessione della password. Ma il motivo per cui è lì è perché è meglio che memorizzare la password.

Motivi: La concessione della password non richiede all'utente di memorizzare la password del suo nome utente nel client. Viene utilizzato solo una volta solo per ottenere il token di accesso.

  1. Memorizzare solo il token è sicuro rispetto alla memorizzazione della password in un'applicazione esterna (dispositivi mobili, app lato server ecc.)
  2. Se l'utente cambia la password all'IDP, l'app dovrà nuovamente chiedere all'utente di inserire la sua nuova password. Questa non è una buona esperienza utente. Ma in tipo di concessione della password, l'app può utilizzare il token di aggiornamento anche quando l'utente ha modificato la password.
risposta data 26.04.2017 - 22:03
fonte

Leggi altre domande sui tag