Estás viendo la documentación de Apigee Edge.
Ve a la
Documentación de Apigee X. información
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 básica de OAuth 2.0 en Apigee Edge.
¿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
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 se denomina "la app". Puede ser una app que se ejecute en un dispositivo móvil o una aplicación web tradicional. La app hace solicitudes al servidor de recursos de datos protegidos activos en nombre del propietario de recursos. 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 Edge es un servidor de recursos cuando se requiere la validación del token 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. Tú puede configurar “extremos de token” en Apigee Edge, en cuyo caso Edge tomará la función de de autorización de dominio.
- 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?” a continuación.
- Token de acceso: Una string larga de caracteres que sirve como credencial y que se usa para acceder a los recursos protegidos. Consulta también "Qué es un acceso token?” a continuación.
- 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.
Dónde encaja Apigee Edge
Con OAuth 2.0, puedes proteger cualquier API con proxy a través de Apigee Edge. Edge incluye un la implementación del servidor de autorización y, como tal, puede generar y validar tokens de acceso. Los desarrolladores comienzan por registrar sus apps en Apigee Edge. 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 OAuthV2 multifacética que implementa las y detalles sobre cada tipo de otorgamiento, lo que facilita la configuración de OAuth en Apigee Edge. 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 aborda uno o más casos de uso, y deberás seleccionar qué otorgamiento tipos que puedes usar según tus propias 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. Uno consideración 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 Edge 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. Viste este flujo cada vez que tu app abre un navegador desde la página de acceso del servidor de recursos y te invita a acceder a tu cuenta (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 otorgamiento también se denomina “tres segmentos” de OAuth.
- 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. Edge 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 interpone” para 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 otorgamientos permiten que el servidor de autorización emita un token de actualización, lo que permite que la app recupere un nuevo token de acceso 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. Con los nombres de "tres patas" flujos de OAuth, el usuario generalmente especifica el nivel de acceso a través de una página de consentimiento (por ejemplo, una página web en el que el usuario selecciona el alcance con una casilla de verificación de 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 IETF OAuth llama a estas claves de cliente ID y secreto de cliente, la IU de Apigee Edge los llama ID de consumidor y secreto de 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. |
|
|
| 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. |
|
|
| 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. |
|
|
| B2C | Existe un usuario final individual (usuario de dispositivo móvil) y las credenciales de usuario se almacenan en el dispositivo móvil. |
|
|
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 app envíe una clave a Edge. La clave debe ser una clave de consumidor válida desde una app de desarrollador de Apigee Edge 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.
Recursos recomendados
Lectura
Consulta Aprende OAuth 2.0.