Um Modelo do dAccess para dApps da Hedera

Neste artigo, vamos discutir e projetar um modelo de autenticação com base em livro-razão para interagir com os dApps da Hedera. Usaremos a HashPack, a carteira da comunidade Hedera, para assinar os prompts de autenticação. Os constructs do AWS da Amazon serão aproveitados para acelerar os detalhes concretos da implementação.

Uma palavra sobre a semântica
Este contexto usa dApps para se referir a qualquer site executado pelo cliente, provavelmente um pacote JavaScript de algum tipo de lógica comercial escrita em uma linguagem de expressão de ordem superior, como a JSX.
Para que um dApp faça operações úteis, muitas vezes ele requer maneiras de manipular dados. Os aplicativos Web atuais fazem isso por meio de chamadas REST para URLs semanticamente elaboradas. Embora a lógica do site por trás desses pontos de extremidade de URL tenda a ser hospedada em servidores centralizados, é devido à execução desses pacotes no lado do cliente, juntamente com sua interação com componentes da Web3, como carteiras e dados de cadeia, que dizemos que, em geral, esses aplicativos são (embora não totalmente) descentralizados. Daí o acrônimo dApp.
Além disso, neste artigo, usamos a noção de acesso descentralizado (dAccess) para nos referirmos a um fluxo completo de autenticação e autorização que alavanca o uso de componentes Web3. Mais sobre isso, mais tarde.

Esperamos que, até o final deste post, você tenha uma base conceitual para um modelo de autenticação descentralizado flexível o suficiente para não apenas suportar vários casos de uso da Hedera Web3, mas também de outras cadeias.

Ao fazer isso, nos esforçaremos para alcançar um alto grau de descentralização para as fases de autenticação e autorização, proporcionando uma experiência de aplicativo robusta e resiliente.

Sabemos disso porque também empregamos esse modelo para nossa plataforma HeadStarter IDO e, até o momento, tudo bem.

Modelos de autenticação centralizada x descentralizada

Sempre que discutimos sobre serviços sem necessidade de permissão, nosso modelo de acesso tradicional consiste, no mínimo, em:

1. Um serviço protegido no qual o usuário está interessado,
2. Um local (geralmente uma página da web, se estivermos falando da internet) onde o usuário pode se autenticar e solicitar autorização para acessar vários aspectos do serviço cercado e,
3. Uma fonte (geralmente um banco de dados) que armazena as credenciais do usuário que são usadas como parte da etapa de autenticação e autorização acima.

Agora, dependendo do grau de complexidade, da confidencialidade do acesso e da segurança, existem vários protocolos que cobrem essas etapas tradicionais da Web2. Embora discutir esses fluxos vá além do escopo deste artigo, mencionarei que os sites da Web em particular, popularizaram o uso do OAuth2.

Conforme discutido na seção de semântica, embora os dApps sejam essencialmente executados de maneira descentralizada, isso se deve à natureza centralizada das tecnologias de banco de dados que compõem o ponto 3, que defende a natureza centralizada geral de tais abordagens. Isso não se refere apenas ao mecanismo de acesso, mas a qualquer coisa que seja compatível com CRUD (_Create, Read, Update, Delete _ou Criar, Ler, Atualizar, Deletar) da perspectiva do serviço.

Portanto, para obedecer ao ethos do movimento Web3 e se esforçar para fornecer mecanismos dAccess para serviços que não tenham um único ponto de falha, seria necessário resolver o aspecto de descentralização do ponto 3.

Descrição do fluxo dAccess

Para a Hedera, alcançamos a mecânica dAccess por:

1. Construindo a etapa de autenticação usando a função de autenticação do HashPack (acesse o site de demonstração oficial para ver com o que isso se parece) para assinar um pedaço de dado confidencial.
2. Construindo nossa lógica de autorização em torno de dados que são acessíveis publicamente (por exemplo, rede espelho da Hedera), provenientes de entidades confiáveis ​​(por exemplo, o site espelho oficial da Hedera).

Se um fluxo for bem-sucedido e o dAccess for concedido, o usuário poderá adquirir acesso à API para caminhos REST protegidos (codificados como uma função lambda na construção ApiGateway Lambda Authorizer da AWS, por exemplo).

Uma realização bem-sucedida de um fluxo dAccess leva à emissão de um cookie de token de sessão anônima (aST) com vida útil, que é devolvido ao usuário e posteriormente fornecido a todas as chamadas de API.

Atualmente, nosso serviço dAccess é composto por 3 pontos de extremidade:

1. Um ping - permite que o front-end consulte se o usuário tem um aST válido. Devido às políticas de segurança de cookies do navegador, o JavaScript do lado do cliente só pode informar se um aST válido está presente (um HTTP 200 é retornado se OK e 4xx caso contrário), mas não pode dizer nada sobre o valor do token em si.
2. Um challenge - usado para criar desafios de pacotes de dados (parte da etapa 1) e discutido na seção a seguir.
3. Um create - se as condições de carga útil estiverem corretas, permite a criação do token de cookie aST de vida útil.

Antes de discutir cada componente principal do dAccess, vamos falar um pouco sobre como cada um desses pontos de extremidade do dAuth desempenha uma função nessa estrutura geral do dAccess.

Fluxo do dAcess

Partida a frio do dAccess: gerando e assinando um desafio seguro na carteira e trocando-o por um novo aST

Tendo todos esses pontos de extremidade disponíveis, se quisermos proteger uma determinada funcionalidade do dApp, primeiro faremos uma consulta no ponto de extremidade de ping para ver se o usuário é um detentor de aST válido. Se não houver tal token disponível, iniciamos um subfluxo de criação de desafio aST, caso contrário, apenas carregamos o serviço protegido e continuamos a execução normalmente.

Se estivermos tentando desafiar a criação de um aST, a parte confidencial referida no ponto 1 é necessária para dar uma sensação de validade temporal aos dados. Se uma terceira parte tentasse forçar a criação de tal pacote, ela teria um tempo limitado antes que o próprio desafio expirasse e sua tentativa de cracking precisaria começar do zero. Este é o pacote que o usuário precisa assinar e chamamos isso de “o desafio” (the challenge).

Para garantir que apenas o criador do serviço possa gerar um desafio, atribuímos a ele um par de chaves público-privada na forma de uma conta Hedera e usamos a chave privada para gerar uma assinatura de partes dos dados que compõem o desafio. Em seguida, incorporamos a assinatura na resposta final que retornamos ao solicitante.

Para o HeadStarter, o desafio atualmente tem essa aparência:

{
 "payload": {
   "url": "headstarter.org",
   "data": {
     "ts": 1663828854253
   }
 },
 "server": {
   "accountId": "0.0.xyz",
   "signature": "962b79c39f5dabad1418c0..."
 }
}

Em seguida, solicitamos ao usuário por meio do HashPack que assine esse desafio. Se aprovado, POSTAREMOS o seguinte pacote para o ponto de extremidade create do aST:

{
 "payload": {
   "url": "headstarter.org",
   "data": {
     "ts": 1663828854253
   }
 },
 "signatures": {
   "server": "962b79c39f5dabad1418c0...",
   "wallet": {
     "accountId": "0.0.zxy",
     "value": "a2f0c19b487aee3e3..."
   }
 }
}

O ponto de extremidade create então verifica se o pacote original recebido pelo usuário foi assinado pelo servidor, se o time-stamp (ts) não seja muito antigo e que o accountId da carteira seja aquele que gerou a assinatura da carteira, buscando a chave pública accountId da carteira de um nó espelho Hedera confiável.

Se essa validação básica for aprovada, podemos ter certeza de que:

1. O usuário assinou algo que o ponto de extremidade challenge criou e, mais importante,
2. O usuário possui essa carteira accountId.

Em seguida, verificamos as outras pré-condições específicas do dapp (por exemplo, um NFT está presente nesta conta?) antes de concluir a tentativa do dAccess.

Se for bem-sucedido, um aST é emitido e devolvido como parte de um Cookie (conforme mencionado anteriormente). Para o HeadStarter, isso se parece com o seguinte:

MC4wLjIxNDUwNDctMTY2Mzg1NzM2NzQ4Mg==.W9Wq1911ffPDU7dJWQKfwVq59YBhIcsgo+BIZCNI8MRxdkz0CrF0Y7npj1c1+SNlf2lZQ2oV4OxR++xUND8hAQ==

O aST é uma lista separada por pontos de strings codificadas em base64 que contém informações básicas sobre a sessão. Informações como:

1. Quando o aST foi gerado - um registro de data e hora.
2. Uma assinatura do servidor do carimbo de data/hora gerado pelo aST para garantir que o aST foi criado por nós, o servidor, e não uma entidade não confiável.
3. O accountId da carteira que assinou o desafio válido original.

Com um carimbo de data/hora de origem válida disponível, o servidor pode invalidar (ou eliminar gradualmente as sessões) em um prazo determinado. Isso também é obtido no lado do cliente por Max-Age-ing do cookie aST.

Autorização do dAccess

Embora a autenticação do dAccess seja, em sua essência, mais ou menos autoexplicativa, a autorização pode ter várias variantes de implementação.

Implementação de autorização comum do dAccess

Por exemplo, pode-se optar por autorizar uma determinada conta cujo ID conhecemos. Isso consultaria a rede espelho apenas pelas informações da conta, certificando-se de que ela existe e usando sua chave pública para validar a assinatura do desafio.

Uma lógica de autorização mais sofisticada implicaria verificar se uma conta possui um token associado, possui uma quantidade mínima de determinado token em sua conta ou possui um token NFT. Todos esses casos de uso transitivos exigiriam acesso aos dados da rede espelho para verificação e são de responsabilidade exclusiva do verificador-autorizador.

Conclusões

Descentralizar o acesso às partes confidenciais do seu dApp não é tão difícil quanto parece. Pode ser facilmente realizado na Hedera, mas não está limitado a ela.

Tendo desenhado o fluxo de interação e os formatos dos pacotes de troca de dados, os únicos pré-requisitos que faltam para implementar tal mecânica em outra cadeia são:

1. A presença de um meio (por exemplo, carteira de software) para o cliente principal assinar pacotes de dados arbitrários.
2. Acesso público aos dados contábeis que a lógica de autorização do dAccess pode consumir.
3. Uma infraestrutura de autorização como a do AWS para acelerar os esforços de desenvolvimento (opcional).

Obrigado por ler.

Artigo escrito por Victor ADĂSCĂLIȚEI. Traduzido por Marcelo Panegali