security - permisos - oauth2 tipos
¿Por qué debería usar OpenID para la autenticación en lugar de OAuth? (2)
He leído repetidamente que OpenID es mejor para la autenticación que OAuth (que es para la autorización), incluyendo varias otras publicaciones en SO.
El caso también parece hacerse en this artículo frecuentemente citado.
Sin embargo, no estoy del todo claro por qué debería favorecer a OpenID para la autenticación, en comparación con un proveedor honesto de OAuth (por ejemplo, Twitter o Facebook OAuth 2.0). Las otras publicaciones de SO que he leído explican los diferentes casos de uso, y comprendo la diferencia entre las funciones para las que están diseñados los protocolos, pero no explican por qué no se puede usar OAuth para autenticar.
Aquí están las razones por las que puedo llegar y mis (quizás erróneas) respuestas:
- OAuth es realmente para Autorización. Hacer que los usuarios se autentiquen utilizando OAuth le otorga a los consumidores más privilegios de los que necesitan.
- Respuesta: Esto es generalmente cierto, pero es mucho más limitado en el caso de OAuth (como la que proporciona Facebook) que me permite solicitar permisos mínimos. De hecho, muchos sitios como Facebook proporcionan OAuth, pero no OpenID, presumiblemente porque están más interesados en autorizar a los consumidores que en autenticar a los clientes. Si quiero brindarles a los clientes más opciones de autenticación, OAuth parece darme eso.
- Las sesiones de OAuth tienden a vivir más tiempo.
- Respuesta: No es relevante si soy un intento del consumidor de autenticar clientes; Haré mi propia gestión de sesión e incluso podré deshacerme de los tokens de OAuth de inmediato tan pronto como termine de autenticar a mis usuarios.
¿Qué ventajas de autenticación ofrece OpenID en comparación con el uso de proveedores de OAuth a gran escala para la autenticación?
El desafío fundamental con el uso de OAuth para la autenticación es que debe asumir su identidad en función del acceso a un recurso determinado. En algunos casos, esto puede ser una suposición válida, pero OAuth no lo garantiza. Si el acceso al recurso que está utilizando para la autenticación se delega a otra parte y está suponiendo una identidad basada en el acceso a ese recurso, entonces esa es una vulnerabilidad que puede permitir que un impostor se autentique en nombre de otro suscriptor. Esto no tiene nada que ver con la honestidad del proveedor de OAuth o su falta, y con una herramienta que se utiliza de una manera para la cual no fue diseñada.
En el caso de Facebook, OAuth puede admitir la autenticación predicada solo para que el suscriptor pueda autorizar la aplicación: si recibe autorización para acceder al perfil de un individuo, significa que el suscriptor debe haberse autenticado en Facebook. Parece que este es un caso de uso compatible. Sin embargo, si Facebook luego permite, por ejemplo, que otras aplicaciones o usuarios autoricen recursos en nombre de sus suscriptores, entonces esa garantía se pierde.
En última instancia, para utilizar OAuth para la autenticación, debe hacer muchas suposiciones. Debe asumir que el usuario que está autentificando y solo ese usuario tiene acceso para delegar un recurso determinado; debe asumir que los datos de solicitud que recibe son suficientes para vincularse a una identidad conocida; debe asumir que el mecanismo de autenticación fue suficiente para la autenticación a un tercero (¿qué pasaría si el archivo no fuera confidencial y se pudiera otorgar acceso anónimo?); y tienes que asumir que estas cualidades son persistentes en el tiempo. OpenID está construido específicamente para esto; OAuth no lo es.
¿Puedes hacer con seguridad estas suposiciones? En el caso de Facebook, posiblemente; parecen estar documentados y soportados casos de uso (no estoy familiarizado con la API específica). Pero en general, no es un caso de uso de OAuth compatible.
La pregunta principal que debe hacerse es si sabe con anticipación a qué proveedores desea brindar asistencia. Si desea permitir que los usuarios utilicen cualquier proveedor a su manera (con soporte de OpenID, como Google, Yahoo, AOL, etc.), debe usar OpenID. Pero si sabe que la mayoría de sus usuarios querrán usar Twitter, Facebook u otro de los proveedores populares de OAuth, úselos.
La terminología técnica es que OAuth proporciona autenticación delegada, mientras que OpenID proporciona autenticación federada. Ahora, es cierto que OAuth es un protocolo de autorización y no un protocolo de autenticación, pero al proporcionarle / me (Facebook) o / account / verify_credentials (Twitter), estos proveedores extendieron OAuth para usarlo como un protocolo de autenticación.
Pero no debes usar OpenID. Es un protocolo muerto.