Puntos a considerar al utilizar OAuth2 y OIDC

Llevo varios proyectos diseñando flujos de autorización y autenticación, es buen momento para realizar una especie de cheatsheet:

Primero los conceptos claves

¿Autorización y autenticación?

• Autorizar es darte la llave de mi casa
• Autenticar es que el perro te reconozca
• Si tienes el rol de desconocido, pobre de ti

¿OAuth y OIDC?

• OAuth: Open Authorization, es un protocolo de Autorización
• OIDC: Open ID Connect, es un protocolo de Autenticación y trabaja sobre OAuth.

¿Qué es un Redirect URI?

• Es una ruta donde el API tercero te entregará un código para que puedas seguir consultando sus recursos. (Lo termino de explicar más adelante)

¿Qué es state?

• Es un valor único generado por ti enviado al servidor de autorización para verificar. (Lo explico con mayor detalle más adelante)

¿Qué es nonce?

• Es similar al state, pero es utilizado para verificar del lado del servidor (en caso de tener uno).

¿Qué son los scopes?

• Son unos valores que te especifica el API tercero, son llaves a grupos de información a los cuales deseas acceder.
• Por ejemplo si deseas email del usuario, suele haber un scope llamado "email" "user:email" o similar, lo agregas donde te dice la documentación y lo recibes al final del flujo

¿Qué flujo debes elegir?

Empecemos con las preguntas importantes

¿Cómo es tu aplicación?

¿Dispones de un servidor donde puedes guardar secretos?

• Sí, Authorization Code Flow
• No, Implicit Grant Flow

¿Es prioritario identificar a la persona que entra a la app?

• Sí, utilizar una variante OIDC (Por ejemplo, OIDC Authorization Code Flow)
• No, utilizar uno de los servicios para obtener el perfil del usuario

¿Qué necesito para empezar?

• Debes registrar un redirect URI
• Te deben dar un Client ID y un Client Secret

¿Redirección o Popup?

Depende del navegador de tu cliente final  y el manejo de tus pantallas.

• Si redireccionas, debes manejar el ingreso de códigos inseguros.
• Chrome en vez de un popup busca abrir una pestaña nueva.
• Internet Explorer y Safari se suele utilizar popup.

Implicit Flow

1. El usuario le da al botón de Iniciar sesión con el Tercero
2. El SPA redirecciona/abre un popup hacia "/authorize" con todos los parámetros como clientID, redirectURI, state ...
   2.1 Si el redirectURI no cuadra con el que registraste, hay tabla!
3. El usuario Acepta sin leer como siempre
4. Vuelve al SPA a la ruta del redirectURI?access_token="123"&state="random"
   4.1 Aquí es donde tu SPA verifica que el state es el mismo al que enviaste
5. Al consultar al API, es recomendable que se verifique que el token viene del tercero, ya sea consultando el perfil o abriendo la llave.

Authorization Code Flow

1. El usuario le da al botón de Iniciar sesión con el Tercero
2. El sitio redirecciona/abre un popup hacia "/authorize" con todos los parámetros como clientID, redirectURI, state ...
   2.1 Si el redirectURI no cuadra con el que registraste, hay tabla!
3. El usuario Acepta sin leer como siempre
4. Vuelve un authorization code, se lo das a tu servidor
   4.1 Aquí es donde tu sitio verifica que el state es el mismo al que enviaste
5. El servidor envia ese authorization code junto al secreto y un nonce
   5.1. Aquí es donde tu servidor verifica que el nonce es el mismo al que enviaste
6. Al consultar al API, es recomendable que se verifique que el token viene del tercero, ya sea consultando el perfil o abriendo la llave.

Client Credentials Flow

• Fácil, una simple llamada al servidor de autenticación.
• Le pueden poner azúcar, cerezas y adornos; pero sigue siendo una llamada de servidor a servidor.
• Pero las empresas no son tontas, solo podrás acceder a información general,
• Te autorizan como aplicación, no bajo el permiso de una persona.

¿Por qué verificar tanto, que si state, nonce y tanto protocolo?

La arquitectura de la aplicación tiene los componentes separados, justo por eso puede ocurrir CSRF o en otras palabras, alguien podría falsificar una de las rutas que se intercambian en el flujo.