Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Rôles de liaison de comptes
Pour créer un connecteur C2C, vous aurez besoin d'un serveur d'autorisation OAuth 2.0 et d'un lien de compte. Pour de plus amples informations, veuillez consulter Flux de travail de liaison de comptes.
OAuth La version 2.0 définit les quatre rôles suivants lors de la mise en œuvre de la liaison de comptes :
-
Serveur d'autorisation
-
Propriétaire de la ressource (utilisateur final)
-
Serveur de ressources
-
Client
Les éléments suivants définissent chacun de ces OAuth rôles :
- Serveur d'autorisation
-
Le serveur d'autorisation est le serveur qui identifie et authentifie l'identité d'un utilisateur final dans un cloud tiers. Les jetons d'accès fournis par ce serveur peuvent relier le compte de plateforme client de l'utilisateur AWS final à son compte de plateforme tierce. Ce processus est appelé « liaison de comptes ».
Le serveur d'autorisation prend en charge la liaison de comptes en fournissant les éléments suivants :
-
Affiche une page de connexion permettant à l'utilisateur final de se connecter à votre système. C'est ce que l'on appelle généralement un point de terminaison d'autorisation.
-
Authentifie l'utilisateur final dans votre système.
-
Génère un code d'autorisation identifiant l'utilisateur final.
-
Transmet le code d'autorisation aux intégrations gérées pour AWS IoT Device Management.
-
Accepte le code d'autorisation des intégrations gérées pour AWS IoT Device Management et renvoie un jeton d'accès que les intégrations gérées pour AWS IoT Device Management peuvent utiliser pour accéder aux données de l'utilisateur final dans votre système. Cela se fait généralement par le biais d'un URI distinct, appelé URI de jeton ou point de terminaison.
Important
Le serveur d'autorisation doit prendre en charge le flux de code d'autorisation OAuth 2.0 à utiliser avec une intégration gérée pour AWS IoT Device Management Connector. Les intégrations gérées pour AWS IoT Device Management prennent également en charge le flux de code d'autorisation avec Proof Key for Code Exchange (PKCE)
. Le serveur d'autorisation doit soit :
-
Émettez des jetons d'accès contenant un identifiant d'utilisateur final ou de propriétaire de ressource extractible, par exemple des jetons JWT
-
Être en mesure de renvoyer l'identifiant de l'utilisateur final pour chaque jeton d'accès émis
Dans le cas contraire, votre connecteur ne sera pas en mesure de prendre en charge le
AWS.ActivateUser
fonctionnement requis. Cela empêchera l'utilisation du connecteur avec les intégrations gérées.Si le développeur ou le propriétaire du connecteur ne gère pas son propre serveur d'autorisation, le serveur d'autorisation utilisé doit fournir une autorisation pour les ressources gérées par la plate-forme tierce du développeur du connecteur. Cela signifie que tous les jetons reçus par les intégrations gérées depuis le serveur d'autorisation doivent fournir des limites de sécurité significatives sur les appareils (la ressource). Par exemple, un jeton d'utilisateur final n'autorise pas les commandes sur l'appareil d'un autre utilisateur final ; les autorisations fournies par le jeton sont mappées aux ressources de la plateforme. Prenons l'exemple de Lights Incorporated. Lorsqu'un utilisateur final lance le flux de liaison du compte avec son connecteur, il est redirigé vers la page de connexion de Lights Incorporated qui fait face à son serveur d'autorisation. Une fois qu'ils se sont connectés et ont accordé des autorisations au client, ils fournissent un jeton qui permet au connecteur d'accéder aux ressources de leur compte Lights Incorporated.
-
- Propriétaire de la ressource (utilisateur final)
-
En tant que propriétaire des ressources, vous autorisez les intégrations gérées pour AWS IoT Device Management à accéder aux ressources associées à votre compte en établissant un lien entre les comptes. Prenons l'exemple de l'ampoule intelligente qu'un utilisateur final a intégrée à l'application mobile Lights Incorporated. Le propriétaire de la ressource fait référence au compte de l'utilisateur final qui a acheté et intégré l'appareil. Dans notre exemple, le propriétaire de la ressource est modélisé comme un compte Lights Incorporated OAuth2 2.0. En tant que propriétaire de la ressource, ce compte fournit les autorisations nécessaires pour émettre des commandes et gérer l'appareil.
- Serveur de ressources
-
Il s'agit du serveur qui héberge les ressources protégées qui nécessitent une autorisation d'accès (données de l'appareil). Le AWS client doit accéder à des ressources protégées pour le compte d'un utilisateur final, et il le fait par le biais d'intégrations gérées pour les connecteurs AWS IoT Device Management après la création de comptes. Si l'on prend l'exemple de l'ampoule intelligente d'avant, le serveur de ressources est un service basé sur le cloud appartenant à Lights Incorporated qui gère l'ampoule une fois qu'elle a été intégrée. Par le biais du serveur de ressources, le propriétaire de la ressource peut envoyer des commandes à l'ampoule intelligente, par exemple l'allumer et l'éteindre. La ressource protégée fournit uniquement des autorisations au compte de l'utilisateur final et à d'autres comptes accounts/entities auxquels il peut avoir accordé des autorisations.
- Client
-
Dans ce contexte, le client est votre connecteur C2C. Un client est défini comme une application qui est autorisée à accéder aux ressources d'un serveur de ressources pour le compte de l'utilisateur final. Le processus de liaison des comptes représente le connecteur, le client, qui demande l'accès aux ressources d'un utilisateur final dans le cloud tiers.
Bien que le connecteur soit le OAuth client, les intégrations gérées pour AWS IoT Device Management exécutent les opérations pour le compte du connecteur. Par exemple, les intégrations gérées pour AWS IoT Device Management demandent au serveur d'autorisation d'obtenir un jeton d'accès. Le connecteur est toujours considéré comme le client car c'est le seul composant qui accède à la ressource protégée (données de l'appareil) sur le serveur de ressources.
Pensez à l'ampoule intelligente qui a été intégrée par un utilisateur final. Une fois le lien du compte établi entre la plateforme client et le serveur d'autorisation de Lights Incorporated, le connecteur lui-même communiquera avec le serveur de ressources pour récupérer des informations sur l'ampoule intelligente de l'utilisateur final. Le connecteur peut ensuite recevoir des commandes de l'utilisateur final. Cela inclut l'allumage ou l'extinction de la lumière en leur nom via le serveur de ressources Lights Incorporated. Ainsi, nous désignons le connecteur en tant que client.