integrar - ¿Cómo y por qué se realiza la validación del token de Google OAuth?

oauth2 api

Question

Entre los tokens de acceso, los tokens de actualización, los ámbitos, las audiencias y las identificaciones de los clientes, me confundí cuando la documentación de Google OAuth me indicó que validara todos los tokens para evitar el problema del agente confuso. El artículo de Wikipedia vinculado solo describe el problema general a un nivel alto, no específico de OAuth o incluso de autenticación de red. Si lo comprendo correctamente, la validación del token ni siquiera es parte de OAuth2, sino que realmente depende de la implementación específica. Ésta es mi pregunta:

¿Cómo y por qué se realiza la validación del token de Google OAuth?

Un ejemplo concreto del problema del diputado confundido en este contexto sería especialmente apreciado. También tenga en cuenta que lo pregunto en el contexto de las aplicaciones totalmente del lado del cliente, si eso hace una diferencia.

Answer 1

¿Cómo estás usando OAuth2? ¿Obtienes un código de autorización e intercambias por token de actualización? ¿O está obteniendo tokens de acceso directamente a través de su interfaz?

Si está recibiendo un código de autorización, ya ha terminado, ya que la verificación de cliente_secret realizada por Google en el backend garantiza que todos los tokens devueltos a cambio del código de autorización se emitieron para su aplicación.

Si está recibiendo un access_token + id_token a través del frontend, entonces debe validar la firma id_token usando las bibliotecas recomendadas, luego validar que el campo ''aud'' en el id_token coincida con el que registró para su aplicación con Google. Para una seguridad completa, también valide el access_token con id_token (el id_token incluye un hash truncado del access_token como ''at_hash''), como se documenta en: https://developers.google.com/accounts/docs/OAuth2Login

Answer 2

Google se refiere específicamente al token de acceso .

En el contexto de OAuth 2.0, el problema del agente confuso se aplica al flujo del protocolo de concesión implícita cuando se utiliza para la autenticación . Lo que Google llama "OAuth 2.0 para aplicaciones del lado del cliente" se basa en el flujo de protocolo de concesión implícito.

Como el flujo implícito expone el token de acceso al usuario final a través del fragmento URI, introduce la posibilidad de que el token de acceso pueda ser manipulado. Una aplicación legítima (un cliente de OAuth) puede convertirse en un agente confuso al aceptar un token de acceso que se emitió a una aplicación diferente (maliciosa), lo que le da acceso a un atacante a la cuenta de la víctima.

El paso crítico para validar el token de acceso es que la aplicación verifica que el token de acceso no se emitió originalmente a una aplicación diferente. Google llama la atención a esto cuando dicen :

Nota: Al verificar un token, es fundamental garantizar que el campo de audiencia en la respuesta coincida exactamente con su ID de cliente registrada en la Consola de API. Esta es la mitigación para el problema de diputado confuso, y es absolutamente vital para realizar este paso.

Como ejemplo simplificado, imagine que hay dos aplicaciones: (1) FileStore, una aplicación de almacenamiento de archivos legítima, y ​​(2) EvilApp. Ambas aplicaciones utilizan el proceso de autenticación de Google para las aplicaciones del lado del cliente. Alice es un usuario final inocente, y su ID de usuario de Google es XYZ.

1. Alice inicia sesión en FileStore utilizando Google.
2. Después del proceso de autenticación, FileStore crea una cuenta para Alice y la asocia con el ID de usuario de Google XYZ.
3. Alice carga algunos archivos a su cuenta de FileStore. Hasta ahora todo está bien.
4. Más tarde, Alice inicia sesión en EvilApp, que ofrece juegos que parecen divertidos.
5. Como resultado, EvilApp obtiene un token de acceso asociado con el ID de usuario de Google XYZ.
6. El propietario de EvilApp ahora puede construir el URI de redireccionamiento para FileStore, insertando el token de acceso que se emitió para la cuenta de Google de Alice.
7. El atacante se conecta a FileStore, que tomará el token de acceso y consultará con Google para ver para qué usuario está. Google dirá que es el usuario XYZ.
8. FileStore le dará al atacante acceso a los archivos de Alice porque el atacante tiene un token de acceso para el usuario de Google XYZ.

El error de FileStore no fue verificar con Google que el token de acceso que se le dio fue realmente enviado a FileStore; El token fue realmente enviado a EvilApp.

Otros han descrito esto mucho más elegante que yo:

• http://www.thread-safe.com/2012/02/more-on-oauth-implicit-flow-application.html
• http://www.thread-safe.com/2012/01/problem-with-oauth-for-authentication.html
• http://tools.ietf.org/html/rfc6749#section-10.16

Espero que esto explique por qué parte de la validación del token de acceso con las aplicaciones del lado del cliente y cómo se relaciona con el confuso problema del diputado.