OAuth explicado para quienes tienen que implementarlo

La documentación de OAuth está escrita para quienes implementan proveedores. Casi todos los que la leen intentan en realidad añadir un botón de «Continuar con Google», y la distancia entre esos dos públicos es la razón por la que el tema parece más difícil de lo que es.

Qué ocurre realmente

Envías al usuario a Google con una nota que dice quién eres y a dónde devolverlo. Inicia sesión en la página de Google: tu aplicación nunca ve la contraseña. Google lo devuelve con un código de vida corta. Tu servidor intercambia ese código, por un canal de servidor a servidor, por un token que demuestra quién es el usuario. Esa es toda la forma del proceso.

Dónde sale mal

• Hacer el intercambio del código en el navegador, lo que filtra el client secret.
• Omitir el parámetro state, que es lo que evita una falsificación de petición entre sitios en el callback.
• Confiar en la afirmación del email sin comprobar que está verificado: un email no verificado es una toma de cuenta esperando a ocurrir.
• Suponer que el ID de usuario del proveedor es una dirección de email. No lo es, y la gente cambia de email.
• Olvidar el caso de vincular cuentas: la misma persona, un segundo proveedor, dos cuentas.

“La parte peligrosa de OAuth no es el protocolo. Son las cinco pequeñas decisiones que el tutorial no menciona.”

Cada una de estas cosas se gestiona por ti cuando la integración con el proveedor es configuración y no código. El inicio de sesión con Google está disponible en todos los planes de Alt Auth, incluido el gratuito, y Apple, Facebook y Microsoft están en los planes superiores.