As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
Funções de vinculação de contas
Para criar um conector C2C, você precisará de um servidor de autorização OAuth 2.0 e vinculação de contas. Para obter mais informações, consulte Fluxo de trabalho de vinculação de contas.
OAuth 2.0 define as quatro funções a seguir ao implementar a vinculação de contas:
-
Servidor de autorização
-
Proprietário do recurso (usuário final)
-
Servidor de recursos
-
Cliente
O seguinte define cada uma dessas OAuth funções:
- Servidor de autorização
-
O servidor de autorização é o servidor que identifica e autentica a identidade de um usuário final em uma nuvem de terceiros. Os tokens de acesso fornecidos por esse servidor podem vincular a conta da plataforma do cliente do usuário AWS final à conta da plataforma de terceiros. Esse processo é conhecido como vinculação de contas.
O servidor de autorização oferece suporte à vinculação de contas fornecendo o seguinte:
-
Exibe uma página de login para que o usuário final faça login no seu sistema. Isso geralmente é chamado de endpoint de autorização.
-
Autentica o usuário final em seu sistema.
-
Gera um código de autorização que identifica o usuário final.
-
Transmite o código de autorização para integrações gerenciadas do AWS IoT Device Management.
-
Aceita o código de autorização das integrações gerenciadas do AWS IoT Device Management e retorna um token de acesso que as integrações gerenciadas do AWS IoT Device Management podem usar para acessar os dados do usuário final em seu sistema. Isso geralmente é concluído por meio de um URI separado, chamado URI de token ou endpoint.
Importante
O servidor de autorização deve suportar o fluxo do Código de Autorização OAuth 2.0 para ser usado com integrações gerenciadas para o AWS IoT Device Management Connector. As integrações gerenciadas para o AWS IoT Device Management também oferecem suporte ao fluxo de código de autorização com o Proof
Key for Code Exchange (PKCE). O servidor de autorização deve:
-
Emita tokens de acesso que contenham ID extraível do usuário final ou do proprietário do recurso, por exemplo, tokens JWT
-
Ser capaz de retornar o ID do usuário final para cada token de acesso emitido
Caso contrário, seu conector não será capaz de suportar a
AWS.ActivateUser
operação necessária. Isso evitará o uso de conectores com integrações gerenciadas.Se o desenvolvedor ou proprietário do conector não mantiver seu próprio servidor de autorização, o servidor de autorização usado deverá fornecer autorização para recursos gerenciados pela plataforma terceirizada do desenvolvedor do conector. Isso significa que todos os tokens recebidos pelas integrações gerenciadas do servidor de autorização devem fornecer limites de segurança significativos nos dispositivos (o recurso). Por exemplo, um token de usuário final não permite comandos no dispositivo de outro usuário final; as permissões fornecidas pelo token são mapeadas para recursos dentro da plataforma. Considere o exemplo da Lights Incorporated. Quando um usuário final inicia o fluxo de vinculação da conta com seu conector, ele é redirecionado para a página de login da Lights Incorporated, que fica na frente do servidor de autorização. Depois de fazer login e conceder permissões ao cliente, eles fornecem um token que dá ao conector acesso aos recursos em sua conta da Lights Incorporated.
-
- Proprietário do recurso (usuário final)
-
Como proprietário do recurso, você permite integrações gerenciadas para o acesso do cliente do AWS IoT Device Management aos recursos associados à sua conta por meio da vinculação de contas. Por exemplo, considere a lâmpada inteligente que um usuário final incorporou ao aplicativo móvel da Lights Incorporated. O proprietário do recurso se refere à conta do usuário final que comprou e integrou o dispositivo. Em nosso exemplo, o proprietário do recurso é modelado como uma conta da Lights Incorporated OAuth2 4.0. Como proprietária do recurso, essa conta fornece permissões para emitir comandos e gerenciar o dispositivo.
- Servidor de recursos
-
Este é o servidor que hospeda recursos protegidos que requerem autorização para acesso (dados do dispositivo). O AWS cliente precisa acessar recursos protegidos em nome de um usuário final, e faz isso por meio de integrações gerenciadas para conectores do AWS IoT Device Management após a vinculação de contas. Considerando a lâmpada inteligente anterior como exemplo, o servidor de recursos é um serviço baseado em nuvem de propriedade da Lights Incorporated que gerencia a lâmpada após sua integração. Por meio do servidor de recursos, o proprietário do recurso pode emitir comandos para a lâmpada inteligente, como ligá-la e desligá-la. O recurso protegido só fornece permissões para a conta do usuário final e outras para as accounts/entities quais ele possa ter fornecido permissão.
- Cliente
-
Nesse contexto, o cliente é seu conector C2C. Um cliente é definido como um aplicativo ao qual é concedido acesso aos recursos em um servidor de recursos em nome do usuário final. O processo de vinculação de contas representa o conector, o cliente, solicitando acesso aos recursos de um usuário final na nuvem de terceiros.
Embora o conector seja o OAuth cliente, as integrações gerenciadas do AWS IoT Device Management realizam operações em nome do conector. Por exemplo, integrações gerenciadas para o AWS IoT Device Management fazem solicitações ao servidor de autorização para obter um token de acesso. O conector ainda é considerado o cliente porque é o único componente que já acessa o recurso protegido (dados do dispositivo) no servidor de recursos.
Considere a lâmpada inteligente que foi integrada por um usuário final. Depois que a vinculação da conta for concluída entre a plataforma do cliente e o servidor de autorização da Lights Incorporated, o próprio conector se comunicará com o servidor de recursos para recuperar informações sobre a lâmpada inteligente do usuário final. O conector pode então receber comandos do usuário final. Isso inclui ligar ou desligar a luz em seu nome por meio do servidor de recursos da Lights Incorporated. Assim, designamos o conector como cliente.