Ho notato che se si dispone di un'app di Twitter di terze parti, si ottiene un token di accesso e un segreto del token di accesso per comunicare con Twitter.
Perché ci sono due codici? Non dovrebbe essere sufficiente?
Significa che ogni app di terze parti deve avere un proprio server che aggiunge il token secret alla richiesta? (Perché se fosse memorizzato nell'app stessa, potrebbe essere decompilato e rivelato il segreto?)
Uno fornisce l'identità, l'altro fornisce l'autenticazione. In generale, l'idea è che l'identità possa essere fornita ai clienti di terze parti, ma il segreto viene utilizzato per la comunicazione tra la terza parte e il server. Il token di accesso consente loro di sapere a quale account è associato. Non è molto diverso dall'avere un nome utente e una password. Posso dirti di inviare a [email protected] un'e-mail senza che tu conosca la password di Bob. Non sono sicuro se questo è specificamente come lo gestisce Twitter, ma è una situazione abbastanza comune per l'applicazione di avere un identificatore e un segreto.
Fa parte dei protocolli di authn / authz OAuth o OAuth-like. Il segreto è pensato solo per essere presentato da server a server, mentre il token può essere instradato attraverso l'agente dell'utente (browser). Il token può anche avere un certo ambito e durata associati ad esso.
Come la risposta sopra descrive anche, un token di Twitter può essere passato alla tua app per interrogare Twitter per conto di un utente che sta usando la tua app.
Ci sono altri flussi di OAuth che sono molto simili a userid / password, ma mantengono ancora questo paradigma.
Leggi altre domande sui tag rest twitter web-service