Me di cuenta de que si tienes una aplicación de terceros de Twitter, obtienes un token de acceso y un token de acceso secreto para comunicarte con Twitter.
¿Por qué hay dos códigos? ¿No debería uno ser suficiente?
¿Esto significa que cada aplicación de terceros debe tener su propio servidor que agregue el token secreto a la solicitud? (Porque si se almacenara en la aplicación misma, ¿podría descompilarse y revelarse el secreto?)
Uno proporciona la identidad, el otro proporciona autenticación. En general, la idea es que la identidad se puede entregar a los clientes del tercero, pero el secreto se utiliza para la comunicación entre el tercero y el servidor. El token de acceso les permite saber con qué cuenta está asociada. No es realmente diferente a tener un nombre de usuario y una contraseña. Puedo decirle que envíe un correo electrónico a [email protected] sin que sepa la contraseña de Bob. No estoy seguro de si esta es la forma específica en que Twitter lo maneja, pero es una situación bastante común que la aplicación tenga un identificador y un secreto.
Es parte de los protocolos OAuth u OAuth-like authn / authz. El secreto solo se debe presentar de servidor a servidor, mientras que el token se puede enrutar a través del agente del usuario (navegador). El token también puede tener un cierto alcance y duración asociados.
Como también se describe en la respuesta anterior, se puede entregar un token de Twitter a su aplicación para consultar twitter en nombre de un usuario que esté usando su aplicación.
Hay otros flujos de OAuth que son muy similares a userid / password, pero aún mantienen este paradigma.
Lea otras preguntas en las etiquetas rest twitter web-service