Quale è più sicuro e perché?
Entrambi sono sicuri, dipende dall'ambiente in cui lo si utilizza.
Non vedo un motivo per cui un passaggio aggiuntivo (scambio codice di autorizzazione per token) viene aggiunto in un flusso di lavoro quando il server può emettere direttamente un token di accesso.
È semplice. Il tuo client non è sicuro. Vediamolo in dettaglio.
Considerare che si sta sviluppando un'applicazione contro Instagram API
, quindi registrare la tua APP con Instagram
e definire quale API's
è necessario. Instagram
ti fornirà client_id
eclient_secrect
Sul tuo sito web hai impostato un link che dice. "Vieni e usa la mia applicazione". Facendo clic su questo, l'applicazione Web dovrebbe effettuare due chiamate a Instagram API
.
First
invia una richiesta Instagram Authentication Server
con i parametri seguenti.
1. `response_type` with the value `code`
2. `client_id` you have get from `Instagram`
3. `redirect_uri` this is a url on your server which do the second call
4. `scope` a space delimited list of scopes
5. `state` with a CSRF token.
Non inviiclient_secret
, non puoi fidarti del client (l'utente e il suo browser che tentano di utilizzare la tua applicazione). Il client può vedere lo script url o java e trovarlo client_secrect
facilmente. Questo è il motivo per cui hai bisogno di un altro passo.
Ricevi un code
e state
. Il code
qui è temporary
e non viene salvato da nessuna parte.
Quindi si effettua una second
chiamata a Instagram API
(dal proprio server)
1. `grant_type` with the value of `authorization_code`
2. `client_id` with the client identifier
3. `client_secret` with the client secret
4. `redirect_uri` with the same redirect URI the user was redirect back to
5. `code` which we have already received.
Poiché la chiamata viene effettuata dal nostro server, possiamo tranquillamente utilizzare client_secret
(che mostra come siamo) con code
cui l'utente ha concesso l' client_id
utilizzo della risorsa.
In risposta avremo access_token