Claves de API frente a autenticación HTTP frente a OAuth en una API RESTful

Estoy trabajando en la construcción de una API RESTful para una de las aplicaciones que mantengo. Actualmente estamos buscando incorporar varias cosas que requieran un acceso y seguridad más controlados. Mientras investigaba cómo asegurar la API, encontré algunas opiniones diferentes sobre qué formulario usar. He visto que algunos recursos dicen que HTTP-Auth es el camino a seguir, mientras que otros prefieren las claves API, e incluso otros (incluidas las preguntas que encontré aquí en SO) juran por OAuth.

Luego, por supuesto, los que prefieren, digamos, claves API, dicen que OAuth está diseñado para aplicaciones que obtienen acceso en nombre de un usuario (según tengo entendido, como iniciar sesión en un sitio que no es de Facebook usando su cuenta de Facebook), y no para un usuario que accede directamente a los recursos en un sitio en el que se ha registrado específicamente (como el cliente oficial de Twitter que accede a los servidores de Twitter). Sin embargo, las recomendaciones para OAuth parecen ser incluso para las necesidades de autenticación más básicas.

Entonces, mi pregunta es: suponiendo que todo se haga a través de HTTPS, ¿cuáles son algunas de las diferencias prácticas entre los tres? ¿Cuándo se debe considerar a uno sobre los demás?

Depende de tus necesidades. Necesitas:

• Identidad: ¿quién afirma estar realizando una solicitud de API?
• Autenticación: ¿son realmente quienes dicen ser?
• Autorización: ¿se les permite hacer lo que intentan hacer?

o los tres?

Si solo necesita identificar a la persona que llama para realizar un seguimiento del volumen o la cantidad de llamadas API, use una clave API simple. Tenga en cuenta que si el usuario al que ha emitido la clave de API la comparte con otra persona, también podrá llamar a su API.

Pero, si también necesita Autorización, es decir, debe proporcionar acceso solo a ciertos recursos según la persona que llama a la API, luego use oAuth.

Aquí hay una buena descripción: http://www.srimax.com/index.php/do-you-need-api-keys-api-identity-vs-authorization/

Las claves de API o incluso los tokens entran en la categoría de mecanismos de autenticación y autorización directos, ya que otorgan acceso a los recursos expuestos de las API de REST. Estos mecanismos directos se pueden utilizar en casos de uso de delegación.

Para obtener acceso a un recurso o un conjunto de recursos expuestos por los puntos finales REST, es necesario verificar los privilegios del solicitante de acuerdo con su identidad. El primer paso del flujo de trabajo es luego verificar la identidad autenticando la solicitud; El paso sucesivo consiste en comprobar la identidad con un conjunto de reglas definidas para autorizar el nivel de acceso (es decir, lectura, escritura o lectura / escritura). Una vez que se completan dichos pasos, una preocupación adicional típica es la tasa de solicitud permitida , es decir, cuántas solicitudes por segundo se le permite al solicitante realizar hacia los recursos dados.

OAuth (autorización abierta) es un protocolo estándar para el acceso delegado , que a menudo utilizan las principales empresas de Internet para otorgar acceso sin proporcionar la contraseña. Como es evidente, OAuth es un protocolo que cumple con las preocupaciones mencionadas anteriormente: Autenticación y Autorización al proporcionar acceso delegado seguro a los recursos del servidor en nombre del propietario del recurso. Se basa en el mecanismo de tokens de acceso que permiten a un tercero acceder al recurso administrado por el servidor en nombre del propietario del recurso. Por ejemplo, ServiceX desea acceder a la cuenta de Google de John Smith en nombre de John, una vez que John haya autorizado la delegación; A continuación, ServiceX recibirá un token basado en el tiempo para acceder a los detalles de la cuenta de Google, muy probablemente solo en acceso de lectura.

El concepto de clave de API es muy similar al Token de OAuth descrito anteriormente. La principal diferencia consiste en la ausencia de delegación: el Usuario solicita directamente la Clave al proveedor de servicios para sucesivas interacciones programáticas. El caso de la clave de API también se basa en el tiempo: la clave como el token de OAuth está sujeta a una concesión de tiempo o un período de vencimiento. Como aspecto adicional, tanto la Clave como el Token pueden estar sujetos a limitación de tarifa por contrato de servicio, es decir, solo se puede atender un número determinado de solicitudes por segundo.

En resumen, en realidad no existe una diferencia real entre los mecanismos tradicionales de autenticación y autorización y las versiones basadas en claves / tokens. Sin embargo, el paradigma es ligeramente diferente: en lugar de seguir reutilizando las credenciales en todas y cada una de las interacciones entre el cliente y el servidor, se utiliza una clave / token de soporte que hace que la experiencia de interacción general sea más fluida y probablemente más segura (a menudo, siguiendo el estándar JWT , claves y Los tokens están firmados digitalmente por el servidor para evitar la creación).

• Autenticación y autorización directas : protocolos basados ​​en claves como una variante de las versiones tradicionales basadas en credenciales.
• Autenticación y autorización delegadas : como los protocolos basados ​​en OAuth, que a su vez utilizan Tokens, nuevamente como una variante de las versiones basadas en credenciales (el objetivo general es no revelar la contraseña a ningún tercero).

Ambas categorías utilizan un flujo de trabajo de verificación de identidad tradicional para la primera interacción con el servidor que posee los recursos interesados.