2012-03-09 26 views
5

Estoy trabajando en la integración de Google Apps en mi aplicación PHP. Ya tengo un sistema de inicio de sesión que asigna un ID de sesión a un usuario (después de ingresar el nombre de usuario y la contraseña), que se almacena en la base de datos cuando el usuario inicia sesión. Los ID de sesión dejan de ser válidos después de un cierto tiempo de inactividad (configurable por el usuario , puede ser 5 minutos, 15, 60 ...). Esa ID de sesión se pasa en la url para verificar si un usuario todavía está conectado. Al cerrar la sesión, la ID de la sesión se elimina de la base de datos.Prácticas recomendadas de Google Apps y OAuth

Permití que las personas inicien sesión con Google almacenando su ID de Google en la base de datos, cuando inician sesión solicitan un token de acceso, consultan la información de usuario, verifican si la ID de Google está en la base de datos y, de ser así, asignan un ID de sesión para este usuario. Como quiero poder consultar otras API, también almaceno el token json de acceso en la base de datos. Cuando un usuario cierra la sesión, el token de acceso también se elimina de la base de datos.

esto funciona, mis usuarios son capaces de iniciar sesión con su cuenta de Google y que pueden consultar la API de usar el señal_acceso almacenada, sin embargo, algunas cosas se sienten torpe de me hacen sentir seguro acerca de mi flujo de trabajo:

  • Si forza_aprobación obtiene un refresh_token, creo que debería usar este token de actualización para obtener un nuevo token de acceso, en lugar de eliminar el antiguo de la base de datos e ingresar uno nuevo cuando el usuario inicie sesión de nuevo. Por otro lado, al iniciar sesión, aún no sé quién es, por lo que no sé qué token de actualización usar. Tal vez estoy malinterpretando para qué sirve el token de actualización. Además, realmente no quiero forzar la aprobación cada vez, por lo que ni siquiera puedo usar refresh_token en ese caso.

  • Como dije antes, los usuarios pueden determinar cuánto tiempo durará su sesión, sin embargo, google access_token siempre expira después de 3600 segundos. Sería realmente estúpido si los usuarios trabajaran una hora en el sistema y luego la API de Google falla repentinamente, obligándolos a iniciar sesión de nuevo. El área de juegos de Google OAuth muestra una casilla de verificación "Token de actualización automática antes de que caduque", pero no veo cómo hacerlo. ¿Debo usar el token de actualización aquí? O simplemente solicite un nuevo token en el fondo (si no estoy forzando la aprobación)?

  • Por el momento, estoy usando la consulta de información del usuario (https://www.googleapis.com/oauth2/v2/userinfo) para encontrar la identificación del usuario, pero también puedo usar tokeninfo (https://www.googleapis.com/oauth2/v1/tokeninfo). Tokeninfo no aparece en el patio de recreo de Oauth, pero el resultado muestra cuánto tiempo el token sigue siendo válido (sin embargo, también puedo calcularlo yo mismo). ¿Es preferible uno sobre el otro?

  • Estoy almacenando todo el objeto json en la base de datos (access_token, id_token, expires_in y token_type) pero creo que mi aplicación funcionará perfectamente si solo almaceno access_token (el único problema que preveo es si expira_en tiempo cambios). ¿Necesito almacenar el id_token por ejemplo?

encuentra la documentación de Google (en developers.google.com) a veces muy escaso, si alguien sabe alguna otras buenas fuentes de información, estoy interesado en ellos también.

Respuesta

4

Creo que podría ser útil si echa un vistazo a las últimas OpenID Connect Specs de donde provienen conceptos como el punto final userinfo. OpenID connect está construido sobre OAuth 2. Hay bastante allí, pero aún así vale la pena echarle un vistazo. This blog article también es muy bueno (como otros en el mismo blog).

Desafortunadamente, no creo que la implementación de Google esté actualizada con el borrador de la última versión, por lo que probablemente sea un objetivo móvil durante algún tiempo. Estas cosas han cambiado mucho durante el año pasado.

Estoy de acuerdo con su primer punto en que debería obtener un nuevo token de acceso cada vez que autentica a un usuario, en lugar de actualizar uno anterior. No sabe quién es el usuario hasta que haya iniciado sesión y le haya otorgado un token de acceso. En general, la vida útil de un token de acceso no está vinculada a la sesión del usuario. Una vez emitido, su aplicación podría usarlo teóricamente para acceder a recursos independientemente de la presencia del usuario. Si desea continuar accediendo al recurso más allá del tiempo de caducidad del token, debe enviar el token de actualización en ese punto para obtener un nuevo token de acceso. Me temo que no sé para qué sirve la función de "actualización automática".

Creo que el tokeninfo de Google es análogo al check_id extremo de OpenID connect, pero acepta un token de acceso o un token de identificación, en lugar de solo este último. Tenga en cuenta que los tiempos de caducidad de los dos pueden diferir. Por lo general, podrá recuperar datos de usuario más detallados del userinfo endpoint que del check_id, que normalmente devolvería el user_id.

No debería necesitar almacenar el id_token. Es un poco como un registro de la autenticación del usuario por parte del servidor de autorizaciones. El token de acceso es lo que su aplicación estará interesada en mantener una vez que haya validado la identidad del usuario.

+0

Muchas gracias por su aporte, leeré los artículos que me brindó y espero que me ayuden en el camino. – Bram

Cuestiones relacionadas