1) ¿Hasta qué punto es OAuth2 más seguro que la autenticación JSON (ambas a través de SSL)?
El contexto es un cliente (un servidor) que consulta otro servidor (a través de API) dentro de una red local usando RESTFul. Antes de que el servidor envíe un JWT, el cliente envía una contraseña para la autenticación (sobre SSL).
2) Entonces, ¿hay una justificación, en cuanto a seguridad, para usar OAuth2?
Puede que no haya una justificación "de seguridad", pero hay otras consideraciones de diseño que vale la pena explorar. En mi opinión, la ventaja más grande de usar OAuth es que abstraes el método de autenticación de los distintos sistemas de autenticación / autorización requeridos (esto es algo que describía Tylerl).
Como ejemplo: comienza con un servicio con el que se autentica utilizando el nombre de usuario / contraseña de JSON. Todo funciona bien, pero decide introducir otro servicio que proporcione una funcionalidad ligeramente diferente. El nuevo servicio también acepta el nombre de usuario y la contraseña a través de JSON.
En algún momento, alguien te señala que el MD5 está dañado o que no estás ingresando tus contraseñas correctamente. No hay problema, puedes arreglar eso. Pero tiene que solucionarlo en ambos (todos) los servicios que realizan autenticación ... ¿Cuántos de estos tiene? ¿Sabes realmente dónde están todos? ¿Cómo puede implementar el cambio en todos los servicios al mismo tiempo?
Al realizar la autenticación contra un Authorization Server , como en OAuth 2.0, elimina parcialmente esta dependencia. Puede cambiar fácilmente los mecanismos de autenticación dentro de este servidor, y mientras sus servicios sigan aceptando tokens de OAuth, no tendrá problemas.
El otro punto importante es que OAuth es un patrón estándar . Cuando se trata de autenticación, adoptar patrones estándar siempre es mejor que implementar sus propios esquemas de autenticación. Además, si deseaba exponer sus servicios a través de Internet en algún momento, el hecho de que acepten los tokens de acceso OAuth facilitaría todo el proceso mucho .
En cuanto a la seguridad, los dos enfoques suenan como si fueran igual de seguros. Ambos autentican tanto al propietario del recurso como al cliente (usando los nombres tal como están definidos por OAuth2, ya que se mezclaron un poco).
Sin embargo, la gran diferencia es que el protocolo OAuth2 estandariza cómo hacerlo. Esto tiene algunas ventajas:
Para resumir: si bien ambos conceptos parecen proporcionar la misma cantidad de seguridad, probablemente sea mejor usar un protocolo diseñado por expertos que usar el suyo, que puede tener fallas de seguridad, tanto por diseño como por implementación.
La ventaja de OAuth sobre el inicio de sesión basado en contraseña es que OAuth me permite otorgarle un permiso limitado para usar mi identidad sin decirle mi contraseña.
Entonces, diga que su sitio publica mensajes en Twitter usando mi cuenta. Quiero darte permiso para utilizar mi cuenta para publicar un tweet, pero no quiero darte acceso ilimitado a mi cuenta de Twitter. No quiero que cambies mi configuración ni sigas a nuevas personas en mi cuenta. Solo quiero que publiques un tweet.
Si te doy mi contraseña, no hay nada que no puedas hacer. Pero si uso OAuth, puedo autenticarme en Twitter e informar a Twitter que tiene mi permiso para usar la API para publicar un mensaje nuevo, pero nada más.
Otra ventaja de OAuth es que puede implicar un proceso de autenticación tan complejo como no estándar como se desee (por ejemplo, SSO a través de SAML, tokens multifactoriales o basados en hardware, o cualquier cosa) y el cliente no necesita saber nada de esto. Solo deben enviar el navegador al proveedor de OAuth y (eventualmente) capturar el código de autenticación cuando se devuelva. Cómo la autenticación realmente sucede no es importante.
JSON y OAuth se usan en conjunto pero son dos cosas diferentes. Si bien JSON es un formato para estructurar datos, OAuth es una especificación que permite a los usuarios compartir los recursos privados en un sitio web con otro sitio sin compartir las credenciales. OAuth no se ha diseñado como un protocolo de autenticación, sino como un "protocolo de autorización delegada". Se puede utilizar como protocolo de autenticación, pero debe tener en cuenta el caso de uso.
Por lo tanto, la pregunta original debería ser, qué versión y qué concesión / flujo usaré para hacer que mi API sea "segura". Según su descripción, tiene un cliente de confianza que necesita acceder a los recursos protegidos. El cliente debe obtener primero el token del servidor de autorización. Esto se puede hacer usando la autenticación básica y, por lo tanto, la Subvención de credenciales del cliente ( enlace ) puede ser una solución viable. Si la solicitud es válida y está autorizada, el servidor de autorización emite un token de acceso en formato json.
Lea otras preguntas en las etiquetas authentication oauth json