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 obtener una vista de nivel superior de la guía de OAuth que proporcionamos.

En este tema, se ofrece una descripción general 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 comiences por revisar la especificación IETF OAuth 2.0. Esta es la definición de OAuth 2.0 de la especificación IETF OAuth 2.0:

“El marco de trabajo 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 recurso mediante la organización de una interacción de aprobación entre el propietario del recurso y el servicio HTTP, o permitir que la aplicación de terceros obtenga acceso en su nombre”.

Lo principal que debes saber es que OAuth 2.0 proporciona una manera para que las aplicaciones obtengan acceso limitado a los recursos protegidos del usuario (por ejemplo, una cuenta bancaria o cualquier otra información sensible que un usuario pueda querer acceso desde una app) sin la necesidad de que el usuario divida sus credenciales de acceso a la app

Sugerencia: Supongamos que encontraste una aplicación que te permite acceder a varias cuentas bancarias. Por ejemplo, la app se usa para ayudarte con los impuestos o para administrar tu presupuesto. Tienes tres cuentas bancarias que deseas administrar con la app y tienes un nombre de usuario y una contraseña diferentes para cada una. Ahora, para que la app acceda a tus cuentas bancarias, necesita esas credenciales sensibles. Básicamente, proporciona esta información sensible a la app. ¿Confías en que la app tiene tus contraseñas y nombres de usuario? ¿Qué sucede si se piratea la app? Ahora debes recordar que debes cambiar las credenciales bancarias de cada cuenta. Este es el problema fundamental que resuelve OAuth 2.0. Continúa leyendo para obtener más información.

El flujo de OAuth 2.0

A continuación, se muestra el flujo general del framework de seguridad de OAuth 2.0. Para analizar este flujo con más detalle en este tema, comenzaremos con un diagrama, que ilustra mucho 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 llamada app. Puede ser una app que se ejecute en un dispositivo móvil o en una app web tradicional. La app realiza solicitudes al servidor de recursos de elementos protegidos en nombre del propietario del recurso. El propietario del recurso debe darle permiso para acceder a los recursos protegidos.
• Propietario del recurso: También se denomina usuario final. Se trata, por lo general, de la persona (u otra entidad) que puede otorgar acceso a un recurso protegido. Por ejemplo, si una app necesita usar datos de uno de tus sitios de redes sociales, eres el propietario de recursos, la única persona que puede otorgar 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 socio de servicios en su extranet B2B. Apigee es un servidor de recursos cada vez que se requiere validación de token de OAuth para procesar solicitudes a la API. El servidor de recursos necesita algún tipo de autorización antes de entregar recursos protegidos a la app.
• 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 los otorgamientos de autorización y emitir los tokens de acceso que le dan a la app acceso a los datos del usuario en el servidor de recursos. Puedes configurar extremos de token en Apigee, en cuyo caso Apigee tomará la función del servidor de autorización.
• Otorgamiento de autorización: Otorga permiso a la app para recuperar un token de acceso en nombre del usuario final. OAuth 2.0 define cuatro “tipos de subsidio” específicos. Consulta Cuáles son los tipos de otorgamiento de OAuth 2.0.
• Token de acceso: Una string larga de caracteres que sirve como credencial y que se usa para acceder a los recursos protegidos. Consulta ¿Qué es un token de acceso?
• Recurso protegido: Datos que le pertenecen al propietario del recurso. Por ejemplo, la lista de contactos del usuario, la información de la cuenta y otros datos sensibles.

Qué lugar ocupa Apigee

Puedes proteger todas las API con proxy a través de Apigee con OAuth 2.0. Apigee incluye una implementación de servidor de autorización y, como tal, puede generar y validar tokens de acceso. Los desarrolladores comienzan por registrar sus apps con Apigee. Las apps registradas pueden solicitar tokens de acceso a través de cualquiera de las cuatro interacciones de tipo de otorgamiento.

Apigee proporciona una política de OAuthV2 multifacética que implementa los detalles de cada tipo de otorgamiento, lo que facilita la configuración de OAuth en Apigee. Por ejemplo, puedes configurar una política que reciba una solicitud de un token de acceso, evalúe todas las credenciales necesarias y muestra un token de acceso si son válidas.

Ten en cuenta que todos los servidores de recursos a los que se realizan llamadas tu proxy de API seguro deben estar detrás de un firewall (es decir, no se debe poder acceder a los recursos mediante otros medios, además del proxy de API u otra API que esté bien protegida).

¿Qué son los tipos de otorgamiento de OAuth 2.0?

Considera otorgar tipos como diferentes rutas o interacciones que puede realizar una app para obtener un token de acceso. Cada tipo de otorgamiento se encarga de uno o más casos de uso, y deberás seleccionar qué tipos de otorgamiento usar en función de tus necesidades. Por lo general, cada tipo de otorgamiento tiene ventajas y desventajas, por lo que tendrás que considerarlas según los casos de uso empresariales. Un aspecto importante es la confiabilidad de las apps que accederán a tus datos. En general, las aplicaciones de terceros son menos confiables que las apps que se desarrollan y usan en una empresa.

Apigee admite los cuatro tipos principales de otorgamiento de OAuth 2.0:

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

Si accedes correctamente, la app recibirá un código de autorización que puede usar para negociar un token de acceso con el servidor de autorización. Por lo general, este tipo de otorgamiento se usa cuando la app reside en un servidor en lugar de en el cliente. Este tipo de concesión se considera muy seguro, ya que la app cliente nunca controla o ve el nombre de usuario o la contraseña del usuario para el servidor de recursos (es decir, la app nunca ve ni administra tus credenciales de Twitter). Este flujo de tipo de concesión también se denomina OAuth de tres segmentos.

• implícita: se considera una versión simplificada del código de autorización. Por lo general, este tipo de otorgamiento se usa cuando la aplicación reside en el cliente. Por ejemplo, el código de la app se implementa en un navegador con JavaScript o con otro lenguaje de programación (en lugar de depender de un servidor web independiente y ejecutarlo). En este flujo de tipo de otorgamiento, el servidor de autorización muestra un token de acceso directamente cuando el usuario se autentica, en lugar de emitir un código de autorización primero. Los otorgamientos implícitos pueden mejorar la capacidad de respuesta de la app en algunos casos, pero esta ventaja se debe evaluar según las posibles implicaciones de seguridad como se describe en la especificación IETF.
• credenciales de contraseña de propietario de recurso: en este flujo, el cliente recibe un token de acceso cuando el servidor de autorización valida el nombre de usuario y la contraseña. Este flujo se recomienda para aplicaciones altamente confiables. Una de las ventajas de este flujo, por ejemplo, la autenticación básica, es que el usuario solo presenta su nombre de usuario y contraseña una vez. A partir de ese momento, se usa el token de acceso.
• credenciales del cliente: evalúa usar situaciones en las que la app cliente actúa en su propio nombre. Es decir, el cliente también es el propietario del recurso. Por lo general, este tipo de concesión se usa cuando la app necesita acceder a un servicio de almacenamiento de datos del backend, por ejemplo. La app necesita usar el servicio para realizar su trabajo y, de lo contrario, el servicio es opaca para el usuario final. Con este tipo de otorgamiento, una app puede recibir un token de acceso cuando se presenta el ID de cliente y las claves secretas del cliente en el servidor de autorización. No se requieren pasos adicionales. 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 string larga de caracteres que sirve como una credencial que se usa para acceder a los recursos protegidos. Los tokens de recursos (también llamados tokens del portador) se pasan en los encabezados de autorización, como se observa a continuación:

$ 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 se apoya en credenciales como nombre de usuario y contraseña. Además, los tokens de acceso se pueden emitir con restricciones para que, por ejemplo, la app pueda leer, pero no escribir o borrar datos en el servidor de recursos. Ten en cuenta que un token de acceso se puede revocar si, por ejemplo, la app está comprometida. En este caso, deberás obtener un nuevo token de acceso para seguir usando la app. Sin embargo, no tendrás que cambiar tu nombre de usuario ni contraseña en el servidor de recursos protegidos (por ejemplo, Facebook o Twitter).

Los tokens de acceso generalmente tienen un 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 app recupere un token de acceso nuevo cuando venza el anterior. Para obtener más detalles sobre los tokens de acceso y actualización, consulta la especificación de IETF OAuth 2.0.

Acceso limitado mediante permisos

A través del mecanismo de alcances, OAuth 2.0 puede otorgar a una app acceso limitado a los recursos protegidos. Por ejemplo, una app puede tener acceso solo a recursos específicos, puede actualizar recursos o solo tener acceso de solo lectura. Según los flujos de OAuth de tres segmentos, 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 alcance con una casilla de verificación o con otro mecanismo).

Registra una app

Todos los clientes (apps) se deben registrar en el servidor de autorización de OAuth 2.0 desde el cual tienen la intención de solicitar tokens de acceso. Cuando registras una app, recibes un conjunto de claves. Una es una clave pública llamada identificador de cliente y la otra es una clave secreta llamada secreto del cliente. Sin estas claves, una app no puede emitir solicitudes de códigos de autorización ni tokens de acceso al servidor de autorización. Ten en cuenta que, si bien la especificación de OAuth de IETF llama a estos ID de cliente y secreto de cliente, la IU de Apigee los llama el ID de consumidor y el secreto del consumidor. Son equivalentes.

Resumen de casos prácticos de OAuth 2.0

El flujo de tipo de otorgamiento de OAuth 2.0 que elegiste implementar depende de tu caso de uso específico, ya que algunos tipos de otorgamiento son más seguros que otros. Tu elección de tipos depende de la confiabilidad de la app cliente y requiere mucho atención, como se describe en la siguiente tabla:

Caso de uso	Credibilidad	Tipos de otorgamiento de autorización de OAuth 2.0 sugeridos	Descripción
B2B (extranet), intranet y otros	Aplicaciones de alta confianza escritas por desarrolladores internos o desarrolladores con una relación comercial confiable con el proveedor de la API. Apps que necesitan acceder a los recursos en su nombre.	Credenciales de clientes	Por lo general, la app también es el propietario del recurso Requiere las claves de ID de cliente y secreto del cliente Requiere que la app esté registrada con el proveedor de servicios
Sitios intranets y portales	Apps de confianza escritas por desarrolladores internos o externos confiables. Un buen ejemplo es acceder al sitio de recursos humanos de tu empresa para realizar selecciones de seguros, enviar opiniones o cambiar información personal.	Contraseña Implícito	Requiere el ID y el secreto del cliente, además del nombre de usuario y la contraseña. Requiere que la app esté registrada con el proveedor de servicios
Apps disponibles públicamente	Las apps no confiables son escritas por desarrolladores externos que no tienen una relación comercial de confianza con el proveedor de API. Por ejemplo, los desarrolladores que se registran para programas de API públicas no suelen ser de confianza.	Código de autorización	Requiere que el usuario acceda al proveedor de recursos de terceros (p. ej., Twitter, Facebook) La app nunca ve el nombre de usuario y la contraseña del usuario Requiere que la app esté registrada con el proveedor de servicios
B2C	Existe un usuario final individual (usuario de dispositivo móvil) y las credenciales de usuario se almacenan en el dispositivo móvil.	Implícito	Requiere que la app esté registrada con el proveedor de servicios. Las credenciales de usuario se almacenan en el dispositivo que ejecuta la app.

Comparación entre OAuth 2.0 y la seguridad de la clave de API

La validación de la clave de API requiere que una aplicación envíe una clave a Apigee. La clave debe ser una clave de consumidor válida de una app de desarrollador de Apigee que esté asociada con el proxy de API. Si por algún motivo necesitas revocar el permiso para que una app cliente realice llamadas a un proxy, debes revocar esa clave de consumidor. Las apps cliente que usen esa clave tampoco podrán acceder al proxy de API. Por otro lado, se puede revocar un token de OAuth en cualquier momento sin revocar las claves de la app. La app puede simplemente solicitar un token nuevo en nombre del usuario y, si se otorga un token, puede seguir usando el proxy de 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, podrías almacenar el ID del usuario que realiza la llamada a la API y usarlo para personalizar llamadas al servicio de destino de backend.

Para obtener detalles sobre la validación de clave de API, consulta Claves de API. Para obtener información sobre el uso de atributos personalizados con tokens OAuth, consulta Personaliza tokens de código y autorización.

Impacto del vencimiento de tokens y los tiempos de purga en el almacenamiento en disco

Nota: Esta sección solo se aplica a los clientes de Apigee Hybrid.

Cuando generas un nuevo token de OAuth con la política de OAuthV2, puedes establecer un tiempo de vencimiento para el token con el atributo ExpiresIn. De forma predeterminada, los tokens se borran del almacenamiento tres días después de que vencen. Si estableces un tiempo de vencimiento largo, como 48 horas, es posible que veas un aumento inesperado en el uso del espacio en disco de Cassandra. Para evitar el uso excesivo de espacio en el disco, puedes establecer un tiempo de vencimiento más corto (se recomienda una hora) o una configuración que cambie la demora posterior al vencimiento de tres días a un período más corto.

Los clientes de Apigee Hybrid pueden cambiar el tiempo de purga predeterminado configurando la siguiente configuración en su archivo de anulaciones:

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

en el que SECONDS es la cantidad de segundos que Apigee esperará para borrar los tokens después de que venzan. Asegúrate de incluir esta estrofa exactamente como está escrita, con las comillas incluidas.

Por ejemplo, para establecer el tiempo de limpieza 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 Aprende OAuth 2.0.