ejemplo - oauth 2.0 php example
OAuth: almacenamiento de token de acceso y secreto (4)
Tenemos varios clientes que utilizan nuestra API para potenciar sus sitios web.
He iniciado una conversación en el trabajo sobre el uso de OAuth para realizar llamadas API autenticadas. Tendremos flujos de dos y tres patas.
Para el flujo de 3 patas, todavía no hemos llegado a un consenso sobre cómo almacenar el token de acceso y el secreto.
El enfoque común a este problema sería hacer que los clientes almacenen el token de acceso y el secreto en su propia base de datos, pero eso está fuera de discusión, ya que los clientes no quieren lidiar con los cambios de código y los problemas de implementación.
Las otras opciones que estamos considerando:
1) Guardar el token de acceso y el secreto en una cookie
2) Guardarlos en la sesión.
No estoy seguro de si alguno de estos es una buena idea. ¿Alguien tiene alguna sugerencia?
Gracias.
Supongo que está hablando del tipo típico de configuración de "Proveedor de servicios", "Consumidor" y "Usuario". No sé si podrá implementar oAuth de tres patas si sus consumidores (cliente) se niegan a realizar cambios.
La sesión y las cookies funcionarían para guardar tokens, pero el problema es que es su consumidor (sus clientes) el que necesita guardarlas, no usted. Las llamadas a su API se realizan en el back-end y, por lo tanto, no hay una sesión real o cookie disponible dentro de ese alcance. Si solo está haciendo llamadas de JavaScript, quizás eso funcione, pero incluso entonces las llamadas se realizan a través de un proxy para no tener problemas de scripts entre dominios.
En cualquier caso, si los tokens se almacenan en la sesión o las cookies, serán claves "temporales" y el Usuario tendrá que volver a autenticarse cuando la sesión o las cookies expiren. Pero no hay nada de malo en eso en lo que respecta a la especificación de oAuth, siempre que a los Usuarios no les importe volver a autenticarse.
Puede consultar la aplicación de ejemplo para .NET escrita con el motor MVC 5 Razor
Tuve el mismo problema cuando implementé un patín de 3 patas. Tomé mi solicitud en línea en Google App Engine y usé Google DataStore para almacenar los tokens de acceso.
Sin embargo, la cuota se menciona here para almacenar datos y enviar consultas. ¡Es la única limitación al usar Google App Engine!
aproximadamente 1) Guardar el token de acceso y el secreto en una cookie
considere a su cliente en un cibercafé y ¿qué sucede después de que él no borra las cookies y la siguiente persona copia estas informaciones?
Me gustaría para DB o sesión de PHP
como Jason mencionó, no es posible que la aplicación del consumidor realice solicitudes autenticadas si no almacenan los tokens necesarios para la autenticación; pueden almacenarlos de la forma que deseen, pero esta es una parte necesaria de la ecuación. Puede ser un sistema de archivos, memcache, base de datos, memoria.
La única forma que veo de usar cookies para almacenarlas es que la aplicación del consumidor establezca estas credenciales de token como una cookie en el navegador del usuario y que el usuario las envíe al consumidor con cada solicitud. Sin embargo, esto parece absurdo como la primera. la aplicación del consumidor tendrá que realizar cambios en su código para manejar esto, y en segundo lugar, las claves secretas de token y token volarán de forma redundante alrededor de la red y el navegador del usuario, lo que puede ser un agujero de seguridad si el propio usuario decide hacer piratería.