Introducción a OAuth 2.0

Esta página se aplica a Apigee y Apigee Hybrid.

Consulta la documentación de Apigee Edge.

Página principal de OAuth: Consulta la página principal de OAuth para ver una vista general de las directrices de OAuth que ofrecemos.

En este tema se ofrece una descripción general básica de OAuth 2.0 en Apigee.

¿Qué es OAuth 2.0?

Hay muchos libros, blogs y sitios dedicados a OAuth 2.0. Te recomendamos que empieces consultando la especificación de OAuth 2.0 de IETF. Esta es la definición de OAuth 2.0 de la especificación IETF de OAuth 2.0:

"El marco de autorización de OAuth 2.0 permite que una aplicación de terceros obtenga acceso limitado a un servicio HTTP, ya sea en nombre de un propietario de recursos organizando una interacción de aprobación entre el propietario de recursos y el servicio HTTP, o permitiendo que la aplicación de terceros obtenga acceso por su cuenta".

Lo más importante que debes saber es que OAuth 2.0 ofrece a las aplicaciones una forma de obtener acceso limitado a los recursos protegidos de un usuario (por ejemplo, una cuenta bancaria o cualquier otra información sensible a la que un usuario quiera acceder desde una aplicación) sin que el usuario tenga que revelar sus credenciales de inicio de sesión a la aplicación.

Flujo de OAuth 2.0

Este es el flujo general del marco de seguridad de OAuth 2.0. En este tema, hablaremos de este flujo con más detalle. Empezaremos con un diagrama que ilustra cómo funciona OAuth 2.0. Si no conoces los términos que se usan en este diagrama, lee esta sección para obtener una introducción rápida.

Términos que debes conocer

• Cliente: también se denomina aplicación. Puede ser una aplicación que se ejecute en un dispositivo móvil o una aplicación web tradicional. La aplicación envía solicitudes al servidor de recursos para obtener recursos protegidos en nombre del propietario de los recursos. El propietario del recurso debe dar permiso a la aplicación para acceder a los recursos protegidos.
• Propietario del recurso: también se denomina usuario final. Por lo general, se trata de la persona (u otra entidad) que puede conceder acceso a un recurso protegido. Por ejemplo, si una aplicación necesita usar datos de uno de tus sitios de redes sociales, tú eres el propietario del recurso, es decir, la única persona que puede conceder a la aplicación acceso a tus datos.
• Servidor de recursos: piensa en el servidor de recursos como un servicio como Facebook, Google o Twitter; o un servicio de recursos humanos en tu intranet; o un servicio de partner en tu extranet B2B. Apigee es un servidor de recursos siempre que se requiera la validación de tokens de OAuth para procesar solicitudes de API. El servidor de recursos necesita algún tipo de autorización para poder servir recursos protegidos a la aplicación.
• Servidor de autorización: el servidor de autorización se implementa de acuerdo con la especificación de OAuth 2.0 y es responsable de validar las autorizaciones y de emitir los tokens de acceso que dan a la aplicación acceso a los datos del usuario en el servidor de recursos. Puedes configurar endpoints de tokens en Apigee, en cuyo caso Apigee asume el rol de servidor de autorización.
• Concesión de autorización: otorga a la aplicación permiso para obtener un token de acceso en nombre del usuario final. OAuth 2.0 define cuatro tipos de concesión específicos. Consulta ¿Qué son los tipos de autorización de OAuth 2.0?
• Token de acceso: una cadena larga de caracteres que sirve como credencial para acceder a recursos protegidos. Consulta ¿Qué es un token de acceso?.
• Recurso protegido: datos propiedad del propietario del recurso. Por ejemplo, la lista de contactos, la información de la cuenta u otros datos sensibles del usuario.

Dónde encaja Apigee

Puedes proteger cualquier API proxyizada a través de Apigee con OAuth 2.0. Apigee incluye una implementación de servidor de autorización y, por lo tanto, puede generar y validar tokens de acceso. Los desarrolladores empiezan registrando sus aplicaciones en Apigee. Las aplicaciones registradas pueden solicitar tokens de acceso a través de cualquiera de las cuatro interacciones de tipo de concesión.

Apigee proporciona una política OAuthV2 multifacética que implementa los detalles de cada tipo de autorización, lo que hace que sea relativamente fácil configurar OAuth en Apigee. Por ejemplo, puedes configurar una política que reciba una solicitud de token de acceso, evalúe todas las credenciales necesarias y devuelva un token de acceso si las credenciales son válidas.

Ten en cuenta que los servidores de recursos a los que llame tu proxy de API seguro deben estar protegidos por un cortafuegos (es decir, no se debe poder acceder a los recursos por ningún medio que no sea el proxy de API u otra API que esté bien protegida).

¿Qué tipos de concesión hay en OAuth 2.0?

Los tipos de concesión son las diferentes rutas o interacciones que puede seguir una aplicación para obtener un token de acceso. Cada tipo de autorización se corresponde con uno o varios casos prácticos, y tendrás que seleccionar los tipos de autorización que quieras usar en función de tus necesidades. En general, cada tipo de subvención tiene ventajas e inconvenientes, y tendrás que sopesar las ventajas y los inconvenientes en función de los casos prácticos de tu empresa. Un aspecto importante que debes tener en cuenta es la fiabilidad de las aplicaciones que accederán a tus datos. Por lo general, las aplicaciones de terceros son menos fiables que las aplicaciones que se desarrollan y se usan en una empresa.

Apigee admite los cuatro tipos principales de concesión de OAuth 2.0:

• Código de autorización: se considera el tipo de autorización más seguro. Antes de que el servidor de autorización emita un token de acceso, la aplicación debe recibir un código de autorización del servidor de recursos. Has visto este flujo cada vez que tu aplicación abre un navegador a la página de inicio de sesión del servidor de recursos y te invita a iniciar sesión en tu cuenta real (por ejemplo, Facebook o Twitter).

Si inicias sesión correctamente, la aplicación recibirá un código de autorización que podrá usar para negociar un token de acceso con el servidor de autorización. Normalmente, este tipo de concesión se usa cuando la aplicación reside en un servidor en lugar de en el cliente. Este tipo de concesión se considera muy seguro porque la aplicación cliente nunca gestiona ni ve el nombre de usuario ni la contraseña del usuario para el servidor de recursos (por ejemplo, la aplicación nunca ve ni gestiona tus credenciales de Twitter). Este flujo de tipo de concesión también se denomina OAuth de tres pasos.

• Implícito: se considera una versión simplificada del código de autorización. Normalmente, este tipo de concesión se usa cuando la aplicación reside en el cliente. Por ejemplo, el código de la aplicación se implementa en un navegador mediante JavaScript u otro lenguaje de secuencias de comandos (en lugar de residir y ejecutarse en un servidor web independiente). En este flujo de tipo de concesión, el servidor de autorización devuelve un token de acceso directamente cuando se autentica al usuario, en lugar de emitir primero un código de autorización. Las concesiones implícitas pueden mejorar la capacidad de respuesta de las aplicaciones en algunos casos, pero esta ventaja debe sopesarse con las posibles implicaciones de seguridad, tal como se describe en la especificación de IETF.
• Credenciales de contraseña del propietario del recurso: en este flujo, se emite un token de acceso al cliente cuando el servidor de autorización valida el nombre de usuario y la contraseña del usuario. Este flujo se recomienda para aplicaciones de alta confianza. Una ventaja de este flujo con respecto a la autenticación básica, por ejemplo, es que el usuario solo tiene que introducir su nombre de usuario y contraseña una vez. A partir de ese momento, se usa el token de acceso.
• Credenciales de cliente: se recomienda usar en situaciones en las que la aplicación cliente actúe en su propio nombre. Es decir, el cliente también es el propietario del recurso. Este tipo de concesión se suele usar cuando la aplicación necesita acceder a un servicio de almacenamiento de datos backend, por ejemplo. La aplicación necesita usar el servicio para hacer su trabajo y, por lo demás, el servicio es opaco para el usuario final. Con este tipo de concesión, una aplicación puede recibir un token de acceso presentando su ID de cliente y sus claves secretas de cliente al servidor de autorización. No tienes que hacer nada más. proporciona una solución de credenciales de cliente lista para usar que es fácil de implementar en cualquier proxy de API.

¿Qué es un token de acceso?

Un token de acceso es una cadena larga de caracteres que sirve como credencial para acceder a recursos protegidos. Los tokens de recursos (también llamados tokens de portador) se transfieren en encabezados de autorización, como este:

$ curl -H "Authorization: Bearer UAj2yiGAcMZGxfN2DhcUbl9v8WsR" \
  http://myorg-test.apigee.net/v0/weather/forecastrss?w=12797282

El servidor de recursos entiende que el token de acceso sustituye a las credenciales, como el nombre de usuario y la contraseña. Además, los tokens de acceso se pueden emitir con restricciones, de modo que, por ejemplo, la aplicación pueda leer datos en el servidor de recursos, pero no escribir ni eliminar datos. Ten en cuenta que un token de acceso se puede revocar si, por ejemplo, la aplicación se ve comprometida. En este caso, tendrás que obtener un nuevo token de acceso para seguir usando la aplicación, pero no tendrás que cambiar tu nombre de usuario ni tu contraseña en el servidor de recursos protegidos (por ejemplo, Facebook o Twitter).

Los tokens de acceso suelen tener una fecha de vencimiento (por motivos de seguridad). Algunos tipos de concesión permiten que el servidor de autorización emita un token de actualización, lo que permite que la aplicación obtenga un nuevo token de acceso cuando caduque el anterior. Para obtener más información sobre los tokens de acceso y de actualización, consulta la especificación de OAuth 2.0 de IETF.

Acceso limitado a través de ámbitos

Mediante el mecanismo de los permisos, OAuth 2.0 puede conceder a una aplicación acceso limitado a recursos protegidos. Por ejemplo, una aplicación puede tener acceso solo a recursos específicos, puede actualizar recursos o puede tener acceso de solo lectura. En los flujos de OAuth de tres vías, el usuario suele especificar el nivel de acceso a través de una página de consentimiento (por ejemplo, una página web en la que el usuario selecciona el ámbito con una casilla u otro mecanismo).

Registrar una aplicación

Todos los clientes (aplicaciones) deben registrarse en el servidor de autorización OAuth 2.0 desde el que quieran solicitar tokens de acceso. Cuando registras una aplicación, recibes un conjunto de claves. Una es una clave pública llamada identificador de cliente y la otra es una clave secreta llamada secreto de cliente. Sin estas claves, una aplicación no puede emitir solicitudes de códigos de autorización ni tokens de acceso al servidor de autorización. Ten en cuenta que, aunque la especificación OAuth de IETF llama a estas claves "ID de cliente" y "secreto de cliente", la interfaz de usuario de Apigee las denomina "ID de consumidor" y "secreto de consumidor". Son equivalentes.

Resumen de los casos prácticos de OAuth 2.0

El flujo del tipo de concesión de OAuth 2.0 que elijas implementar dependerá de tu caso de uso específico, ya que algunos tipos de concesión son más seguros que otros. La elección de los tipos de concesión depende de la fiabilidad de la aplicación cliente y requiere una reflexión muy cuidadosa, tal como se describe en la siguiente tabla:

Seguridad de OAuth 2.0 frente a la de las claves de API

Para validar una clave de API, una aplicación debe enviar una clave a Apigee. La clave debe ser una clave de consumidor válida de una aplicación de desarrollador de Apigee asociada al proxy de API. Si por algún motivo necesitas revocar el permiso de una aplicación cliente para hacer llamadas a un proxy, debes revocar esa clave de consumidor. Las aplicaciones cliente que usen esa clave tampoco podrán acceder al proxy de la API. Por otro lado, un token de OAuth se puede revocar en cualquier momento sin revocar las claves de la aplicación. La aplicación puede solicitar un nuevo token en nombre del usuario y, si se le concede, puede seguir usando el proxy de la API.

Otra diferencia entre una clave de API y un token es que un token puede incluir atributos de metadatos que puedes recuperar y usar más adelante. Por ejemplo, puedes almacenar el ID del usuario que hace la llamada a la API y usarlo para personalizar las llamadas al servicio de destino del backend.

Para obtener información sobre la validación de claves de API, consulta Claves de API. Para obtener información sobre cómo usar atributos personalizados con tokens de OAuth, consulta Personalizar tokens y códigos de autorización.

Impacto de la caducidad de los tokens y de los tiempos de purga en el almacenamiento en disco

Cuando generas un token de OAuth con la política OAuthV2, puedes definir una fecha de caducidad para el token con el atributo ExpiresIn. De forma predeterminada, los tokens se eliminan del almacenamiento tres días después de que caduquen. Si defines un tiempo de vencimiento largo, como 48 horas, es posible que observes un aumento inesperado del uso del espacio en disco de Cassandra. Para evitar que se utilice demasiado espacio en disco, puedes definir un tiempo de vencimiento más corto (se recomienda una hora) o una configuración que cambie el retraso posterior al vencimiento de tres días por un periodo más breve.

Los clientes de Apigee hybrid pueden cambiar el tiempo de purga predeterminado configurando lo siguiente en su archivo de anulaciones:

runtime:
  cwcAppend:
    "conf_keymanagement_oauth.access.token.purge.after.seconds": "SECONDS"

Donde SECONDS es el número de segundos que Apigee esperará para purgar los tokens después de que caduquen. Asegúrate de incluir esta estrofa exactamente como está escrita, con las comillas incluidas.

Por ejemplo, para definir el tiempo de purga en una hora después del vencimiento, haz lo siguiente:

runtime:
  cwcAppend:
    "conf_keymanagement_oauth.access.token.purge.after.seconds": "3600"

Recursos recomendados

Lectura

Consulta Información sobre OAuth 2.0.