Ninguno, siempre y cuando sea más de HTTPS. Pero aquí hay algunas cosas en las que debe pensar:
a) ¿Quiénes son los clientes? ¿Se invocará esto desde JavaScript en el navegador? entonces, ¿confía en que las aplicaciones del cliente invoquen esto desde el lado del servidor y no necesariamente envíen el u / p al navegador?
B) ¿Esta API se utilizará únicamente como B2B (o App to App) y no necesita el contexto del usuario final?
c) No estoy seguro de qué tan grande es su organización y cuántas API diferentes en varias plataformas está exponiendo. Si son demasiados, cuando implementa la autenticación básica, debe realizar algunos rituales una y otra vez para cada conjunto de API (dependiendo de la separación física / lógica) como: crear reglas de firewall entre su servidor de aplicaciones y el servidor LDAP (suponiendo que servidor de autenticación centralizado), realice la lógica de validación de credenciales, tenga algún tipo de sistema para restablecer contraseñas, etc.
La respuesta corta no es un problema con la autenticación básica, siempre que sea más de HTTPS.
EDITAR: Después de que la pregunta fue actualizada y algunos comentarios.
a) No hay nada de malo en realizar la autenticación básica siempre que
– HTTPS está habilitado.
– Entiende que su punto final de aplicación / servicio tiene que “Validar la credencial contra el Repositorio de Identidad”, además de administrar los nueve metros completos de contraseña segura, restablecimiento de contraseña, etc.
b) Dado que la pregunta ahora se cambia a “¿Cuáles son las desventajas?”, bueno, todo depende de la cantidad de API, plataformas, tiempo y otros factores. Lo que es una ventaja para un tipo de arquitectura (ya sea que esté usando OAuth o algún otro servicio de emisión de tokens) puede no necesariamente traducirse en una desventaja para otros.
Tomemos la autenticación básica para API
- ¿Cómo sería Golang una buena opción para un servidor WebSocket para una aplicación PHP?
- ¿Cuál es el mejor lenguaje del lado del servidor para una aplicación que hace tantas solicitudes CURL?
- ¿Cuál es la mejor opción para el desarrollo de sitios web?
- ¿Cómo puede distinguir a un desarrollador web aficionado de un profesional?
- Si necesita construir su propio marco de JavaScript, ¿cómo lo estructurará?
Ventajas: todos lo saben … es fácil de habilitar e integrar. La mayoría de las plataformas admitirán y ya está.
Desventaja: nada si solo habla de Simple Service, habilitado con HTTPS y su aplicación puede realizar la autenticación de forma segura.
La mejor manera de responder esto es comparar la autenticación básica con otras alternativas y compararla con sus requisitos, la arquitectura de seguridad general, etc.
Si tengo que elegir una estrategia AuthN y AuthZ para las API, simplemente elegiría “Basado en token”, esto aborda lo siguiente:
a) Los tokens se emiten desde un servicio central.
b) solo que el servicio central puede realizar la autenticación (validar credenciales).
c) Puede controlar la lógica de autorización en cuanto a lo que ese token puede o no hacer cuando se usa para invocar el Servicio X o el Servicio Y
d) Tiene la opción de introducir la Propagación de identidad.
e) Puedes intercambiar / cambiar un token por otro.
Estoy usando libremente el token de trabajo, por lo que el concepto es genérico y puede aplicar esto con OAuth o WS-Trust, casi los conceptos son los mismos.
