Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
Funciones de vinculación de cuentas
Para crear un conector C2C, necesitará un servidor de autorización OAuth 2.0 y una vinculación de cuentas. Para obtener más información, consulte Flujo de trabajo para vincular cuentas.
OAuth La versión 2.0 define las cuatro funciones siguientes al implementar la vinculación de cuentas:
-
Servidor de autorización
-
Propietario del recurso (usuario final)
-
Servidor de recursos
-
Cliente
A continuación se define cada una de estas OAuth funciones:
- Servidor de autorización
-
El servidor de autorización es el servidor que identifica y autentica la identidad de un usuario final en una nube de terceros. Los tokens de acceso proporcionados por este servidor pueden vincular la cuenta de plataforma del cliente del usuario AWS final y su cuenta de plataforma de terceros. Este proceso se denomina vinculación de cuentas.
El servidor de autorización admite la vinculación de cuentas al proporcionar lo siguiente:
-
Muestra una página de inicio de sesión para que el usuario final inicie sesión en el sistema. Por lo general, esto se denomina punto final de autorización.
-
Autentica al usuario final en el sistema.
-
Genera un código de autorización que identifica al usuario final.
-
Transfiere el código de autorización a las integraciones gestionadas de AWS IoT Device Management.
-
Acepta el código de autorización de las integraciones gestionadas de AWS IoT Device Management y devuelve un token de acceso que las integraciones gestionadas de AWS IoT Device Management pueden utilizar para acceder a los datos del usuario final de su sistema. Por lo general, esto se completa a través de un URI independiente, denominado URI de token o punto final.
importante
El servidor de autorización debe admitir el flujo de códigos de autorización OAuth 2.0 para poder utilizarlo con integraciones administradas para AWS IoT Device Management Connector. Las integraciones administradas para AWS IoT Device Management también admiten el flujo de códigos de autorización con Proof Key for Code Exchange (PKCE)
. El servidor de autorización debe:
-
Emita tokens de acceso que contengan un identificador extraíble de usuario final o propietario del recurso, por ejemplo, tokens JWT
-
Poder devolver el ID de usuario final de cada token de acceso emitido
De lo contrario, el conector no podrá soportar la
AWS.ActivateUser
operación requerida. Esto impedirá el uso del conector con las integraciones gestionadas.Si el desarrollador o propietario del conector no tiene su propio servidor de autorización, el servidor de autorización utilizado debe autorizar los recursos administrados por la plataforma de terceros del desarrollador del conector. Esto significa que cualquier token que las integraciones gestionadas reciban del servidor de autorización debe proporcionar límites de seguridad significativos en los dispositivos (el recurso). Por ejemplo, un token de usuario final no permite ejecutar comandos en el dispositivo de otro usuario final; los permisos que proporciona el token se asignan a los recursos de la plataforma. Considere el ejemplo de Lights Incorporated. Cuando un usuario final inicia el flujo de vinculación de cuentas con su conector, se le redirige a la página de inicio de sesión de Lights Incorporated, situada junto a su servidor de autorización. Una vez que han iniciado sesión y han concedido los permisos al cliente, proporcionan un token que permite al conector acceder a los recursos de su cuenta de Lights Incorporated.
-
- Propietario del recurso (usuario final)
-
Como propietario del recurso, usted permite que un cliente de AWS IoT Device Management acceda a los recursos asociados a su cuenta mediante la vinculación de la cuenta. Por ejemplo, considere la bombilla inteligente que un usuario final ha incorporado a la aplicación móvil Lights Incorporated. El propietario del recurso se refiere a la cuenta de usuario final que compró e incorporó el dispositivo. En nuestro ejemplo, el propietario del recurso se modela como una cuenta de Lights Incorporated OAuth2 2.0. Como propietaria del recurso, esta cuenta proporciona permisos para emitir comandos y administrar el dispositivo.
- Servidor de recursos
-
Este es el servidor que aloja los recursos protegidos a los que se requiere autorización para acceder (datos del dispositivo). El AWS cliente necesita acceder a los recursos protegidos en nombre de un usuario final y lo hace a través de integraciones administradas para los conectores de AWS IoT Device Management posteriores a la vinculación de la cuenta. Si tomamos como ejemplo la bombilla inteligente de antes, el servidor de recursos es un servicio basado en la nube propiedad de Lights Incorporated que administra la bombilla una vez que se ha incorporado. A través del servidor de recursos, el propietario del recurso puede enviar comandos a la bombilla inteligente, como encenderla y apagarla. El recurso protegido solo proporciona permisos a la cuenta del usuario final y a otras cuentas a las accounts/entities que pueda haber dado permiso.
- Cliente
-
En este contexto, el cliente es su conector C2C. Un cliente se define como una aplicación a la que se le concede acceso a los recursos de un servidor de recursos en nombre del usuario final. El proceso de vinculación de cuentas representa al conector, el cliente, que solicita el acceso a los recursos de un usuario final en la nube de terceros.
Aunque el conector es el OAuth cliente, las integraciones administradas de AWS IoT Device Management realizan operaciones en nombre del conector. Por ejemplo, las integraciones administradas para AWS IoT Device Management realizan solicitudes al servidor de autorización para obtener un token de acceso. El conector sigue considerándose el cliente porque es el único componente que accede al recurso protegido (datos del dispositivo) en el servidor de recursos.
Pensemos en la bombilla inteligente que ha incorporado un usuario final. Una vez finalizada la vinculación de cuentas entre la plataforma del cliente y el servidor de autorización de Lights Incorporated, el propio conector se comunicará con el servidor de recursos para recuperar información sobre la bombilla inteligente del usuario final. A continuación, el conector puede recibir comandos del usuario final. Esto incluye encender o apagar la luz en su nombre a través del servidor de recursos de Lights Incorporated. Por lo tanto, designamos el conector como cliente.