La respuesta a su pregunta puede ser a nivel de código, protocolo o arquitectura. Intentaré resumir aquí la mayoría de los problemas de nivel de protocolo, ya que eso suele ser crítico en el análisis de pros y contras. Tenga en cuenta que OAuth2 es mucho más que Credenciales de contraseña de propietario de recursos que, según la especificación, existe por "razones heredadas o de migración", se considera "mayor riesgo que otros tipos de concesión" y la especificación establece explícitamente que los clientes y los servidores de autorización "DEBE minimizar el uso de este tipo de subvención y utilizar otros tipos de subvención siempre que sea posible".
Todavía hay muchas ventajas de usar ROPC sobre la autenticación básica, pero antes de entrar en eso, comprendamos la diferencia de protocolo básico entre OAuth2 y la autenticación básica. Por favor tengan paciencia conmigo mientras les explico esto y vendré a ROPC más tarde.
Flujos de autenticación de usuario
Hay cuatro roles definidos en la especificación OAuth2. Con ejemplos, son:
- Propietario del recurso: el usuario que tiene acceso a algún recurso, por ejemplo, en su caso, diferentes usuarios pueden tener diferentes niveles de acceso a la API REST;
- El cliente: generalmente la aplicación que está usando el usuario y necesita acceso al recurso para proporcionar servicios al usuario;
- Servidor de recursos: la API REST en su caso; y
- Servidor de autorización: el servidor en el que se presentan las credenciales del usuario y que autenticará al usuario.
Cuando se ejecuta una aplicación cliente, se le otorga acceso a los recursos en función del usuario. Si un usuario tiene privilegios de administrador, los recursos y las operaciones disponibles para el usuario en REST API pueden ser mucho más que un usuario sin privilegios de administrador.
OAuth2 también permite la posibilidad de utilizar un único servidor de autorización con múltiples clientes y para múltiples recursos. Como ejemplo, un servidor de recursos puede aceptar la autenticación del usuario con Facebook (que puede actuar como servidor de autorización en tal caso). Entonces, cuando el usuario ejecuta una aplicación (es decir, el cliente), envía al usuario a Facebook. El usuario escribe sus credenciales en Facebook y el cliente recupera un "token" que puede presentar al servidor de recursos. El servidor de recursos mira el token y lo acepta después de verificar que Facebook, de hecho, lo emitió y permite al usuario acceder al recurso. En este caso, el cliente nunca ve las credenciales del usuario (es decir, sus credenciales de Facebook).
Pero supongamos que está administrando las identidades de sus usuarios (y tiene un servidor de autorización) en lugar de Facebook, que ya le otorga tokens a su cliente. Ahora, supongamos que también tiene un socio y desea permitir que su aplicación (es decir, el cliente) acceda a su API REST. Con autenticación básica (o incluso ROPC), el usuario proporcionará credenciales a ese cliente que lo enviará al servidor de autorización. El servidor de autorización proporcionará un token que el cliente puede usar para acceder a los recursos. Desafortunadamente, esto significa que las credenciales del usuario ahora también son visibles para ese cliente. Sin embargo, no querrá que la aplicación de un socio (que podría ser externa a su organización) sepa siquiera la contraseña de un usuario. Eso es un problema de seguridad ahora. Para lograr ese objetivo,
Por lo tanto, con OAuth2, uno idealmente no usaría ROPC en tales casos, sino que usaría uno diferente, como el flujo de código de autorización. Esto protege a cualquier aplicación de conocer las credenciales del usuario que se presentan solo al servidor de autorización. Por lo tanto, las credenciales de un usuario no se filtran. Los mismos problemas se aplican con la autenticación básica, pero en la siguiente sección, explicaré cómo ROPC sigue siendo mejor porque las credenciales del usuario aún no necesitan ser almacenadas por el cliente en ROPC para el acceso persistente de los clientes.
Tenga en cuenta que cuando el usuario va al servidor de autorización, el servidor de autorización también puede pedirle al usuario que confirme que desea permitir que el cliente acceda a los recursos en su nombre o no. Es por eso que se llama el servidor de autorización porque el proceso de autorización de un cliente para acceder a los recursos está implicado en el proceso. Si el usuario no autoriza al cliente, no obtendrá acceso a los recursos. Del mismo modo, si el usuario no tiene acceso a los recursos, el servidor de autorización puede denegar el acceso y no emitir un token.
En la autenticación básica, incluso el servidor de autorización y el servidor de recursos se combinan en una sola entidad. Por lo tanto, el servidor de recursos quiere autorizar al usuario, por lo que solicita las credenciales del cliente. El cliente proporciona esas credenciales que utiliza el servidor de recursos para autenticar al usuario. Esto significa que múltiples servidores de recursos requerirán esencialmente credenciales del usuario.
Emisión de tokens
Los clientes obtienen tokens del servidor de autorización, los mantienen cerca y los usan para acceder a los recursos (más detalles sobre los tokens mismos a continuación). Los clientes nunca conocen la contraseña del usuario (en flujos que no sean ROPC) y no necesitan almacenarla. En ROPC, a pesar de que los clientes conocen la contraseña del usuario, aún no necesitan almacenarla porque usan estos tokens para acceder a los recursos. Por el contrario, en la autenticación básica, si un cliente no quiere que el usuario proporcione credenciales en cada sesión, entonces el cliente debe almacenar la contraseña del usuario para que pueda proporcionarla la próxima vez. Este es un inconveniente importante para usar la autenticación básica a menos que el cliente sea solo una aplicación web, en cuyo caso, las cookies pueden abordar algunas de estas preocupaciones. Con aplicaciones nativas, eso generalmente no es una opción.
Hay otro aspecto de OAuth2 que está relacionado con cómo se emiten los tokens y cómo funcionan. Cuando un usuario proporciona credenciales al servidor de autorización (incluso en ROPC), el servidor de autorización puede proporcionar uno o más de los dos tipos de tokens: 1) token de acceso y 2) token de actualización.
Los tokens de acceso se envían al servidor de recursos que otorgará acceso a los recursos después de validarlo, y generalmente tienen una vida útil corta, por ejemplo, 1 hora. El cliente envía tokens de actualización al servidor de autorización para obtener otro token de acceso cuando caduca y, por lo general, tiene una larga vida útil (por ejemplo, de unos días a meses o incluso años).
Cuando el cliente proporciona el token de acceso al servidor de recursos, mira el token y, después de validarlo, mira dentro del token para determinar si permite el acceso o no. Mientras el token de acceso sea válido, el cliente puede seguir usándolo. Digamos que el usuario cierra la aplicación y la inicia al día siguiente, y el token de acceso ha caducado. Ahora el cliente realizará una llamada al servidor de autorización y presentará el token de actualización suponiendo que no ha caducado. El servidor de autorización, dado que ya emitió el token, lo verifica y puede determinar que el usuario no necesita proporcionar las credenciales nuevamente y, por lo tanto, le da otro token de acceso al cliente. El cliente ahora tiene acceso al servidor de recursos nuevamente. Así es como típicamente las aplicaciones cliente para Facebook y Twitter solicitan credenciales una vez y luego no requieren que el usuario proporcione las credenciales nuevamente. Estas aplicaciones nunca necesitan conocer las credenciales de los usuarios y, sin embargo, pueden acceder a los recursos cada vez que el usuario inicia la aplicación.
Ahora el usuario puede ingresar al servidor de autorización (por ejemplo, en su perfil de usuario de Facebook), cambiar la contraseña sin afectar las aplicaciones de ningún cliente. Todos continuarán funcionando correctamente. Si el usuario pierde un dispositivo en el que ya tenía una aplicación con tokens de actualización, puede decirle al servidor de autorización (por ejemplo, Facebook) que "cierre la sesión" de esas aplicaciones que el servidor de autorización (es decir, Facebook) logrará al no respetar ninguna actualizar tokens y obligar al usuario a proporcionar credenciales nuevamente cuando intentan acceder a los recursos a través de esas aplicaciones.
JWT es simplemente el formato de token que generalmente se usa con OAuth2 y OpenID Connect. Los métodos para firmar el token y validarlo también están estandarizados con bibliotecas disponibles para aquellos en lugar de que cada servidor de recursos implemente una solución más. Por lo tanto, la ventaja radica en la reutilización del código que ha sido examinado y sigue siendo compatible.
Implicaciones de seguridad
La autenticación básica será más débil cuando alguno de los escenarios anteriores esté en la imagen. También hay un extenso modelo de amenaza para OAuth2 disponible para desarrolladores que pueden usar las sugerencias para evitar vulnerabilidades comunes en sus implementaciones. Si sigue el modelo de amenaza, verá que muchas vulnerabilidades relacionadas con la implementación (como el redirector abierto y CSRF) también están cubiertas en él. No pasé por la comparación de aquellos contra la autenticación básica en esta respuesta.
La última gran ventaja de OAuth2 es que el protocolo está estandarizado y múltiples servidores de autorización, clientes y servidores de recursos lo cumplen. Numerosas bibliotecas están disponibles para los desarrolladores, que se mantienen de modo que a medida que se encuentran problemas de seguridad en las implementaciones, las bibliotecas se actualizan al tiempo que permiten la interoperabilidad.
Conclusión
Si está escribiendo una nueva aplicación, IMO, el caso ideal sería evitar tanto la autenticación básica como la ROPC debido a los problemas inherentes a ellas. Sin embargo, cada aplicación tiene diferentes necesidades, plazos, competencia del desarrollador, etc., por lo que la decisión es caso por caso. Pero incluso si no tuviera más necesidad que la autenticación básica, al elegirla, podría encerrarse en una arquitectura que puede no ser fácil de ampliar (por ejemplo, si tiene varios servidores en el futuro, no necesariamente querría tener el usuario proporciona credenciales a cada uno de ellos, en lugar de simplemente proporcionar una vez al servidor de autorización, que puede entregar tokens, etc.)
Tenga en cuenta que no abordé su comentario sobre cómo se envían las credenciales a través del cable porque se pueden proteger mediante TLS o un protocolo similar, o una prueba de posesión, etc. Como alguien ya sugirió, la codificación de base 64 es 0 seguridad, por favor no ser engañado por eso. Las diferencias mencionadas anteriormente generalmente están en el nivel arquitectónico y, por lo tanto, ahí es donde me enfoqué porque la arquitectura es la más difícil de cambiar una vez implementada.
Azure Active Directory B2C Basic , un servicio en el que trabajo y que se lanzó recientemente para la vista previa pública, permite que una aplicación de terceros use AAD como servidor de autorización con interoperabilidad con IDP sociales (como Facebook, Google, etc.). También permite a los usuarios crear sus propias cuentas en lugar de usar IDP sociales y que luego se pueden usar con fines de autenticación. También hay otros servicios similares (por ejemplo, otro que conozco es auth0) que pueden usar los desarrolladores para externalizar completamente la autenticación y la gestión de usuarios para sus aplicaciones y recursos. Los desarrolladores utilizan las mismas características de protocolos que mencioné anteriormente para desacoplar el servidor de autorización (AAD), un recurso (por ejemplo, sus API REST), el cliente (por ejemplo, sus aplicaciones móviles) y los usuarios. Espero que esta explicación ayude un poco.