Lo que necesita saber sobre OAuth2 e iniciar sesión con Facebook

En caso de que te estés preguntando qué es OAuth2, es el protocolo que permite a cualquiera iniciar sesión con su cuenta de Facebook. Activa el botón "Iniciar sesión con Facebook" en aplicaciones y sitios web en todas partes.

Este artículo le muestra cómo funciona "Iniciar sesión con Facebook" y explica el protocolo detrás de todo. Aprenderá por qué querría iniciar sesión con Facebook, Google, Microsoft o una de las muchas otras empresas que admiten OAuth2.

Este artículo le muestra cómo funciona "Iniciar sesión con Facebook" y explica el protocolo detrás de todo. Aprenderá por qué querría iniciar sesión con Facebook, Google, Microsoft o una de las muchas otras empresas que admiten OAuth2.

Veremos dos ejemplos: por qué Spotify usa Facebook para permitirle iniciar sesión en la aplicación móvil de Spotify y por qué Quora usa Google y Facebook para permitirle iniciar sesión en su sitio web.

Lectura adicional en SmashingMag:

• Cuatro formas de crear una aplicación móvil
• Cómo construir interfaces de usuario honestas y ayudar a los usuarios a tomar mejores decisiones
• Cómo mantener la popularidad de su aplicación de Android después del lanzamiento
• Listas de reproducción de Spotify para impulsar sus sesiones de codificación y diseño
  

Antes de OAuth2

OAuth2 ganó una batalla de estándares hace unos años. Es el único protocolo de autenticación admitido por los principales proveedores. Google recomienda OAuth2 para todas sus API, y Graph API de Facebook solo admite OAuth2.

La mejor manera de entender OAuth2 es mirar lo que vino antes y por qué necesitábamos algo diferente. Todo comenzó con la autenticación básica.

Autenticación básica

Los esquemas de autenticación se centran en dos preguntas clave: ¿Quién es usted? ¿Y puedes probarlo?

La forma más común de hacer estas dos preguntas es con un nombre de usuario y una contraseña. El nombre de usuario dice quién eres y la contraseña lo prueba.

Basic Auth fue el primer esquema de autenticación web. Suena divertido, pero "Autenticación básica" era su nombre real en la especificación publicada por primera vez en 1999.

La autenticación básica permite que los servidores web soliciten estas credenciales de una manera que los navegadores entiendan. El servidor devuelve un código de respuesta HTTP de 401 (lo que significa que se requiere autenticación) y agrega un encabezado especial a la respuesta, denominado WWW-Authenticate , con un valor especial de Basic .

Cuando el navegador ve este código de respuesta y este encabezado, muestra un cuadro de diálogo de inicio de sesión emergente:

La gran parte de Basic Auth es su simplicidad. No tienes que escribir una pantalla de inicio de sesión. El navegador maneja todo eso y simplemente envía el nombre de usuario y la contraseña al servidor. También le da al navegador la oportunidad de manejar la contraseña de manera especial, ya sea recordándola para el usuario, obteniéndola de un complemento de un tercero o tomando las credenciales del usuario de su sistema operativo.

La desventaja es que no tienes ningún control sobre la apariencia de la pantalla de inicio de sesión. Eso significa que no puede diseñarlo o agregar una nueva funcionalidad, como "¿Olvidó su contraseña?" enlace o una opción para crear una nueva cuenta. Si desea más personalización, deberá escribir un formulario de inicio de sesión personalizado.

Formularios de inicio de sesión personalizados

Los formularios de inicio de sesión personalizados le brindan todo el control que pueda desear. Escribe un formulario HTML y solicita las credenciales. Luego envía el formulario y maneja el inicio de sesión de la forma que desee. Obtiene el control total: puede diseñarlo, solicitar más detalles o agregar más enlaces.

Algunos sitios web, como WordPress, usan un formulario simple para la pantalla de inicio de sesión:

LinkedIn permite a los usuarios iniciar sesión o crear una cuenta en la misma página, sin tener que ir a otra parte del sitio web:

El inicio de sesión basado en formularios es muy popular, pero tiene un gran problema fundamental: los usuarios tienen que decirle al sitio web su contraseña.

Mantener los secretos en secreto

En los círculos de seguridad, llamamos secreto a una contraseña. Es una información que solo tú tienes y prueba que eres tú. El secreto también puede ser algo más que una contraseña; Hablaremos más sobre eso un poco más tarde.

Un sitio web puede tomar todas las medidas de seguridad del mundo, pero si el usuario comparte su contraseña, esa seguridad desaparece. Los piratas informáticos violaron el sitio web de Gawker en 2010 y expusieron las contraseñas de muchos usuarios. Si bien esto fue un problema para Gawker, el problema no terminó ahí. La mayoría de las personas reutilizan las contraseñas, por lo que los piratas informáticos tomaron los datos filtrados de Gawker e intentaron iniciar sesión en sitios web más críticos, como Gmail, Facebook y eBay. Cualquiera que usara una contraseña de Gawker para cosas más importantes perdió mucho más que los últimos chismes sobre el video sexual de Hulk Hogan.

Asegurarse de que sus usuarios no reutilicen una contraseña para varias cuentas es la primera mitad del problema, y ​​es imposible. Siempre que las personas tengan que crear diferentes cuentas en Internet, reutilizarán sus contraseñas.

La segunda mitad del problema es almacenar las contraseñas de forma segura.

Cuando alguien inicia sesión en su aplicación, debe verificar su contraseña, y eso significa que necesita una copia para verificarla. Podría almacenar todos los nombres de usuario y contraseñas en una base de datos en algún lugar, pero ahora corre el riesgo de perder esas contraseñas o ser pirateado. La mejor práctica es usar una función hash, como una de las funciones SHA-2. Esta función encripta los datos de una manera que nunca podrá recuperar, pero puede replicar el encriptado: "mi contraseña" se codificará en algo como bb14292d91c6d0920a5536bb41f3a50f66351b7b9d94c804dfce8a96ca1051f2 cada vez.

Y ahora estamos en la hierba alta: te estoy diciendo cómo implementar protocolos criptográficos. A continuación, tendré que explicar cómo agregar sal a sus datos y qué libros de texto leer sobre los ataques de intermediarios. Todo lo que quería hacer era escribir una aplicación y ahora debe convertirse en un experto en seguridad. Necesitamos dar un paso atrás.

OAuth2

Probablemente no seas un experto en seguridad. Incluso si lo eres, todavía no te confiaría mi contraseña. OAuth2 le ofrece una mejor manera.

Como ejemplo, uso Spotify en mi iPad. Le pago a la compañía $10 al mes para escuchar música. Spotify me da acceso en solo tres dispositivos, así que necesito una contraseña para asegurarme de que nadie más use mi cuenta. Mi cuenta de Spotify no es un gran problema de seguridad. Ser pirateado no sería el fin del mundo, pero la compañía tiene mi tarjeta de crédito, así que quiero asegurarme de que estoy seguro.

Casi nunca inicio sesión en Spotify, así que no quiero crear otra cuenta y tener que recordar otra contraseña. Spotify me da una mejor opción:

Puedo usar mi cuenta de Facebook para iniciar sesión. Cuando toco ese botón, Spotify me envía a facebook.com e inicio sesión allí. Esto puede parecer un pequeño detalle, pero es el paso más importante de todo el proceso.

Los programadores de Spotify podrían haber escrito un formulario de inicio de sesión y luego enviado mi nombre de usuario y contraseña a Facebook con una API de back-end, pero hay dos grandes razones por las que no quiero que hagan eso:

• No confío en Spotify con mi contraseña de Facebook. Uso Facebook para conectarme con amigos y no quiero que me pirateen. No confío en que Spotify manejará la contraseña correctamente. Tampoco confío en que evitará la tentación de hacer algo divertido con él. Tal vez intentaría almacenarlo para poder usarlo más tarde. Tal vez tiene un error que lo escribe en un archivo en algún lugar antes de enviarlo a Facebook, por lo que un pirata informático podría apoderarse de él. Lo siento, Spotify; Simplemente no soy del tipo confiado.
• No quiero dejar que Spotify haga todo. Quiero que Spotify reproduzca música. No quiero que se publique en los muros de mis amigos cuando escucho a las Spice Girls. Tampoco quiero dejar que descargue mi lista de amigos y los moleste para que se unan a Spotify. Si le diera a Spotify mi contraseña de Facebook, podría iniciar sesión como yo en Facebook; podría hacer cualquier cosa que yo pudiera hacer.

También hay dos grandes razones por las que Spotify no quiere hacer eso:

• Facebook tiene múltiples opciones para iniciar sesión. . Puedo iniciar sesión con mi nombre de usuario y contraseña o puedo iniciar sesión con la aplicación de Facebook. También puedo recuperar mi contraseña de Facebook u obtener ayuda que Spotify no puede brindarme. Si solo le diera mi contraseña a Spotify, no obtendría ninguna de esas opciones.
• Mi secreto podría no ser una contraseña. . Una contraseña es suficiente seguridad para mi cuenta de Spotify de $ 10 por mes, pero podría no ser suficiente para mi banco o algo aún más importante. Hay muchos otros secretos que podría proporcionar: podría tener una tarjeta inteligente o podría estar viviendo en una película de Misión Imposible y usar un escáner de retina.

No estoy en una película de Misión Imposible, pero en el mundo real, muchas empresas usan la autenticación de dos factores, como una contraseña y algo más. El método más común es usar su teléfono. Cuando quieres iniciar sesión, la empresa te envía un texto con un código especial que dura unos minutos; luego ingresa el código o usa una aplicación para ingresarlo.

Ahora la empresa está segura de que nadie puede iniciar sesión en su cuenta sin su teléfono. Si alguien roba tu contraseña, no podrá iniciar sesión. Mientras no pierdas tu teléfono, todo está seguro.

Facebook no es el único proveedor de OAuth2. Cuando inicio sesión en Quora con mi cuenta de Google, Google me dice qué le gustaría hacer a Quora y me pregunta si está bien:

Podría estar bien si permito que Quora vea mi dirección de correo electrónico y los datos básicos de mi perfil, pero no quiero que administre mis contactos. OAuth2 me muestra todo el acceso que Quora quiere, permitiéndome elegir a qué doy acceso.

Entonces, esas son las ventajas de OAuth2. Vamos a ver cómo funciona.

Cómo funciona OAuth2

Facebook, Google y la mayoría de los demás proveedores de OAuth2 tratan a los clientes nativos de forma diferente a los clientes web. Los clientes nativos se consideran más seguros y obtienen tokens y tokens de actualización que pueden durar meses. Los clientes web obtienen tokens mucho más cortos, que generalmente se agotan cuando el usuario cierra el navegador o no ha hecho clic en el sitio web durante un tiempo.

En ambos casos, el proceso de inicio de sesión es el mismo. La diferencia está en la frecuencia con la que el usuario necesita pasar por él.

El inicio de sesión de OAuth2 sigue estos pasos generales:

1. El usuario intenta hacer algo que requiere autenticación. Esto podría ser tan simple como abrir una aplicación o hacer clic en el botón "Iniciar sesión".
2. La aplicación o el sitio web determina que el usuario aún no ha iniciado sesión e inicia el proceso de inicio de sesión. Lo hace abriendo una página web y enviándola a una URL especial en Facebook, Google o cualquier otro sitio web que proporcione su OAuth2.

Abrir una nueva ventana del navegador para el proveedor de OAuth2 es un paso crucial. Eso es lo que permite a los proveedores mostrar sus propios formularios de inicio de sesión y pedir a cada usuario la información de inicio de sesión que necesite. La mayoría de las aplicaciones hacen esto con una vista web integrada.

Junto con la URL de inicio de sesión del proveedor, debe enviar algunos parámetros de URL que le indiquen al proveedor quién es usted y qué desea hacer:

• client_id Esto le dice al proveedor de OAuth2 cuál es su aplicación. Deberá registrar su aplicación con anticipación para obtener una identificación de cliente.
• redirect_uri Esto le dice al proveedor a dónde quieres ir cuando hayas terminado. Para un sitio web, esto podría ser volver a la página principal; una aplicación nativa podría ir a una página que cierra la vista web.
• response_type Esto le dice al proveedor lo que quiere recuperar. Normalmente, este valor es token , para indicar que desea un token de acceso, o code , para indicar que desea un código de acceso. Los proveedores también pueden ampliar este valor para proporcionar otros tipos de datos.
• scope Esto le dice al proveedor a qué quiere acceder su aplicación. Así es como Google sabe que Quora está pidiendo acceso para administrar tus contactos. Cada proveedor tiene un conjunto diferente de ámbitos.

Hay campos adicionales que pueden agregar más seguridad o ayudar con el almacenamiento en caché. Ciertos proveedores también pueden agregar más campos, pero estos cuatro son los más importantes.

Una vez que su aplicación abre la vista web, el proveedor se hace cargo. Es posible que solo soliciten un nombre de usuario y una contraseña simples, o que presenten múltiples pantallas solicitando cualquier cosa, desde el nombre de su maestro favorito hasta el apellido de soltera de su madre. Eso depende de ellos. La parte importante es que, cuando el proveedor termine, lo redirigirá a usted y le dará un token.

Se trata de las fichas

Cuando se complete el proceso, el proveedor le dará un token y un tipo de token. Hay dos tipos de tokens: tokens de acceso y tokens de actualización. El tipo de cliente que tenga determinará qué tipos de tokens puede solicitar.

Cuando inicio sesión en mi aplicación Spotify, puedo permanecer conectado durante meses, porque se supone que solo yo uso mi teléfono. Facebook confía en la aplicación de Spotify para administrar los tokens, y confío en que la aplicación de Spotify no perderá los tokens.

Cuando el token de acceso expira (normalmente, en una o dos horas), Spotify puede usar el token de actualización para obtener uno nuevo.

El token de actualización dura meses. De esa manera, solo tengo que iniciar sesión en mi teléfono unas pocas veces al año. La desventaja es que si pierdo ese token de actualización, otra persona podría usar mi cuenta durante meses. El token de actualización es tan importante que iOS proporciona un llavero para tokens, donde se asegura de cifrarlos y almacenarlos de forma segura.

Usar OAuth2 en una aplicación web funciona de la misma manera. En lugar de usar una vista web, puede abrir la solicitud de inicio de sesión de OAuth2 en un marco, un iframe o una ventana separada. También puede abrirlo en la página actual, pero esto haría que perdiera todo el estado de la aplicación JavaScript cada vez que alguien necesite iniciar sesión.

Cuando inicio sesión en Quora con mi navegador web, no obtengo un token de actualización. Quieren que se agote el tiempo de espera del token y me pidan que vuelva a iniciar sesión cuando cierre el navegador o simplemente me vaya a almorzar. Los clientes que no son de confianza no pueden actualizar el token porque no se puede confiar en ellos para conservar el token de actualización importante. Es más seguro pero menos conveniente, porque le pedirán que inicie sesión nuevamente con mucha más frecuencia.

Usando OAuth2 en su aplicación

Ahora sabe cómo funciona OAuth2, pero probablemente no quiera implementar su propio cliente OAuth2. Puede ir a leer la especificación completa de OAuth 2.0 de 75 páginas si tiene problemas para dormir, pero no es necesario. Algunas grandes bibliotecas están disponibles para su uso.

iOS tiene soporte incorporado para OAuth2. Corrina Krych tiene un tutorial muy útil sobre el uso de OAuth 2.0 con Swift. Le explica cómo obtener un token, cómo integrar las vistas en su aplicación y dónde almacenar sus tokens.

Android también tiene soporte incorporado para OAuth2. Debo admitir que no estoy tan familiarizado con él porque me concentro en iOS, pero hay algunas buenas secciones en la documentación para mostrarle ejemplos y algunas bibliotecas de código abierto para que sea aún más fácil.

JavaScript no tiene soporte integrado para OAuth2, pero hay clientes para todas las principales bibliotecas de JavaScript. React es totalmente compatible con OAuth2. AngularJS tiene soporte de terceros para OAuth2.0 para muchos proyectos. Incluso escribí uno de ellos.

Una vez que tenga un cliente OAuth2, deberá elegir un proveedor.

¿En quién confías?

La gran suposición aquí es que confío más en Facebook que en Spotify. No tengo una buena razón para eso. Facebook no hace pública su seguridad interna, y no hay una buena forma de auditarla. Spotify tampoco. No hay Consumer Reports para la seguridad de OAuth2. Básicamente confío en Facebook porque es más grande. Confío en Facebook porque otras personas lo hacen.

También confío más en Facebook cada vez que hago clic en el botón "Iniciar sesión con Facebook". Si Facebook pierde mi contraseña, los piratas informáticos tendrán acceso no solo a mi cuenta de Facebook, sino también a mi cuenta de Spotify y a cualquier otro servicio en el que haya iniciado sesión con mi cuenta de Facebook. La ventaja es que solo hay un lugar donde tengo que restablecer mi contraseña para solucionar el problema.

No tengo que confiar en Facebook, pero tengo que confiar en alguien. Alguien tiene que autenticarme. Necesito elegir el proveedor en el que confío.

Elegir un proveedor de OAuth2

Wikipedia mantiene una lista de proveedores de OAuth, pero a usted no le importaría la mayoría de ellos. Los grandes son Facebook y Google. También es posible que desee buscar en Amazon o Microsoft.

Los cuatro son grandes y fáciles de integrar. Facebook proporciona instrucciones para registrar una aplicación. Google tiene pasos similares. La idea básica es que cree una cuenta de desarrollador y luego cree una ID de aplicación. Luego, el proveedor le proporciona una identificación de cliente que puede usar para realizar solicitudes.

También puede elegir varios proveedores. Quora le permite iniciar sesión con Facebook o Google; debido a que ambos usan OAuth2, puede usar el mismo código para ambos.

Lo que falta en OAuth2

OAuth2 hace un muy buen trabajo al resolver un problema complejo, pero le faltan un par de cosas:

• El estándar no es completamente estándar. Nunca he podido escribir un solo cliente OAuth2 que pueda iniciar sesión tanto en Facebook como en Google sin algunas declaraciones if . Cada uno interpreta la especificación de manera diferente, y hay pequeños detalles diferentes para cada uno. También siempre tienen ideas diferentes sobre qué alcances proporcionar. El uso de una biblioteca para integrarse con OAuth2 ayuda mucho con este problema, pero nunca será 100% transparente en el código de su aplicación.
• Cerrar sesión es complicado. . Cada aplicación o sitio web que usa OAuth2 tiene un botón de cierre de sesión, pero la mayoría simplemente olvidará los tokens sin invalidarlos. La aplicación se olvidará de todos sus tokens actuales y permitirá que otra persona inicie sesión, pero sus tokens seguirán siendo válidos. Si un pirata informático robó su token, aún podría usarlo e iniciar sesión como usted.

Hay una especificación separada para invalidar tokens OAuth2, pero muchos de los principales proveedores no la adoptaron. OAuth2 no proporciona una forma de recuperación si un pirata informático obtiene su token de actualización; aunque puede eliminar su copia local del token, el pirata informático aún lo tendrá. Muchos proveedores le brindan una forma de suspender su cuenta, pero no existe una forma estándar de hacerlo.

En defensa de OAuth2, este es un problema difícil, porque muchos proveedores usan criptografía de clave pública para crear tokens sin estado. Esto significa que el servidor no recuerda los tokens que ha creado, por lo que no puede olvidarlos más adelante.

El otro gran problema con OAuth2 es que depende de su proveedor. Cuando Facebook deja de funcionar, también lo hace el botón "Iniciar sesión con Facebook" en su aplicación. Si Google decide comenzar a cobrarle por admitir OAuth2 o exige que comparta sus ganancias con él, no hay nada que pueda hacer. Esta es la espada de doble filo de confiar en un proveedor: Están haciendo mucho por ti, pero tienen control sobre tus usuarios.

OAuth2 dirige el mundo

Incluso con un par de funciones faltantes y una gran dependencia, OAuth2 sigue siendo una excelente opción. Hace que sea fácil para los usuarios iniciar sesión en su aplicación, no tener que recordar una contraseña para cada sitio web y confiar en su seguridad. OAuth2 es una opción muy popular. Domina la industria. Ningún otro protocolo de seguridad se acerca a la adopción de OAuth2.

Ahora ya sabe de dónde proviene OAuth2 y cómo funciona. Tome decisiones inteligentes sobre en quién confiar, deje de leer artículos sobre el almacenamiento seguro de contraseñas cifradas y dedique más tiempo a escribir su increíble aplicación.