Elección del Flujo Oauth 2.0 según Roles del Cliente y Servidor

¿Cómo elegir el flujo adecuado de OpenAuthorization 2.0?

Elegir el flujo de OAuth 2.0 correcto para tu aplicación puede marcar la diferencia entre una implementación segura y una vulnerable. La elección del flujo no solo depende del tipo de aplicación que estés desarrollando, sino también de sus características de seguridad y sus necesidades de usuario. Aquí te ofrecemos una guía práctica para ayudarte a tomar decisiones informadas sobre qué flujo implementar y en qué circunstancias.

¿Qué roles son fundamentales en OAuth 2.0?

Antes de adentrarnos en los flujos específicos, es crucial recordar los roles principales que participan en OAuth 2.0:

• Cliente (client): Habitualmente, es la aplicación que inicia la solicitud de autorización.
• Authorization Server: API encargada de emitir y validar tokens.
• Resource Owner: El usuario que proporciona el acceso.
• Resource Server: Endpoints que serán consumidos usando el token emitido por el Authorization Server.

Estos roles son la base para determinar el flujo adecuado, pero para simplificar, nos enfocaremos principalmente en los roles del cliente y del Resource Server.

¿El cliente es el Resource Owner?

Si el cliente y el Resource Owner son la misma entidad, debes optar por el Client Credentials Flow. Este flujo no considera al usuario directamente y es ideal para:

• APIs externas de la misma organización que quieren consumir otra API.
• Herramientas de línea de comandos que se ejecutan en entornos seguros.

¿El cliente es una aplicación web en el servidor?

En caso afirmativo, el Authorization Code Flow es el camino a seguir. Este flujo es el más utilizado y se aplica en la mayoría de las situaciones donde una web app se ejecuta en un servidor.

¿Se le confían al cliente las credenciales del usuario?

Si decides que el cliente puede manejar las credenciales del usuario, puedes usar el Resource Owner Password Flow. Sin embargo, esto solo es recomendable para sistemas antiguos que no permiten re-direccionamiento y debe ser el último recurso debido a sus implicaciones de seguridad.

¿El cliente es una app nativa o mobile?

Para apps de escritorio, móviles o Single Page Apps donde no se pueden almacenar secretos como el Client Secret, la recomendación es usar Authorization Code Flow con Proof-Key for Code Exchange. Este método es seguro aunque también puedes considerar el Implicit Flow con For Post, pero solo bajo el contexto de OpenID Connect.

Si estás considerando el Implicit Flow para autorización, es mejor evitarlo debido a sus riesgos de seguridad complejos. Es un método que ha sido tradicionalmente usado pero hoy desaconsejado especialmente para Single Page Apps.

¿Cuál es el reto con las Single Page Apps?

Implementar OAuth en Single Page Apps presenta desafíos únicos. Muchas veces es más sencillo implementar un backend que lidiar con los flujos diferentes que existen. Si tienes una Single Page App, considera lo siguiente:

1. Implementar un backend: Esta es la mejor opción, ya que hoy en día muchas Single Page Apps ya incluyen un backend para Renderización del Lado del Servidor (Server Side Rendering) o un backend para frontends específicos.
2. Usar Authorization Code Flow con PKCE: Si no puedes implementar un backend, este flujo es una solución segura.
3. Para OpenID Connect, emplear Implicit Flow con For Post: Aun así, necesitarás una parte de backend por seguridad.
4. Último recurso: Implicit Flow: Solo si no queda otra opción, pero ten en cuenta los grandes desafíos de seguridad.

Recuerda, los flujos en OAuth están diseñados para ser versátiles y ajustarse a las necesidades y limitaciones de tus aplicaciones. Como desafío, te invito a proponer en los comentarios una alternativa de sistema de preguntas para elegir el flujo de OAuth adecuado. ¡Continúa explorando y aprendiendo para lograr implementaciones seguras y efectivas!