Autenticação e autorização em seu aplicativo
A segurança é essencial para os aplicativos Web modernos. O Fluid Framework, como parte de sua arquitetura de aplicativo Web, é uma parte importante da infraestrutura para segurança. O Fluid Framework é uma arquitetura em camadas e os conceitos relacionados à autenticação são implementados com base no serviço Fluid ao qual ele está se conectando. Isso significa que, embora exista temas comuns de autenticação em todos os serviços Fluid, os detalhes e as especificações serão diferentes para cada serviço.
Serviço do Azure Fluid Relay
Cada locatário do serviço do Azure Fluid Relay que você cria recebe uma ID de locatário e sua própria chave secreta exclusiva do locatário.
A chave secreta é um segredo compartilhado. Tanto seu aplicativo/serviço quanto o serviço do Azure Fluid Relay o conhecem. Como a chave secreta do locatário está vinculada exclusivamente ao seu locatário, usá-la para assinar solicitações garante ao serviço do Azure Fluid Relay que as solicitações são provenientes de um usuário autorizado do locatário.
A chave secreta é como o serviço do Azure Fluid Relay sabe que as solicitações são provenientes do seu aplicativo ou serviço. Isso é crítico, porque, uma vez que o serviço do Azure Fluid Relay pode confiar que seu aplicativo está fazendo as solicitações, ele pode confiar nos dados que você envia. Esse também é motivo pelo qual é importante que o segredo seja manipulado com segurança.
Cuidado
Qualquer pessoa com acesso ao segredo pode representar seu aplicativo ao se comunicar com o serviço do Azure Fluid Relay.
Tokens Web JSON e o serviço do Azure Fluid Relay
O Azure Fluid Relay usa tokens Web JSON (JWTs) para codificar e verificar dados assinados com sua chave secreta. Os Tokens Web JSON são um bit de sinal de JSON que pode incluir informações adicionais sobre direitos e permissões.
Observação
As especificidades do JWTs estão além do escopo deste artigo. Para obter mais informações sobre o padrão JWT, consulte Introdução aos Tokens Web JSON.
Embora os detalhes da autenticação sejam diferentes entre os serviços Fluid, diversos valores devem sempre estar presentes.
- containerId O serviço Fluid precisa da ID do contêiner para identificar qual serviço corresponde ao contêiner de chamada. Note: o JWT chama esse campo de documentId, mas o serviço Fluid espera uma ID de contêiner nesse campo.
- tenantId: o serviço do Azure Fluid Relay usa a ID de locatário para recuperar o segredo compartilhado que ele usará para autenticar sua solicitação.
- scopes: os escopos definem as permissões do contêiner de chamada. O conteúdo do campo de escopos é flexível, permitindo que você crie suas próprias permissões personalizadas.
{
"alg": "HS256",
"typ": "JWT"
}.{
"documentId": "azureFluidDocumentId",
"scopes": [ "doc:read", "doc:write", "summary:write" ],
"user": {
"name": "TestUser",
"id": "Test-Id-123"
},
"iat": 1599098963,
"exp": 1599098963,
"tenantId": "AzureFluidTenantId",
"ver": "1.0"
}.[Signature]
O modo do usuário indica se a conexão está no modo de leitura ou leitura/gravação. Isso pode ser exibido no campo connections em AzureAudience. As permissões do escopo do token podem ser atualizadas na Função do Azure sem servidor na função generateToken.
const token = generateToken(
tenantId,
documentId,
key,
scopes ?? [ "Token Scope" ],
user
);
Os escopos de token junto com os modos e o comportamento do contêiner são os seguintes:
| Escopo do token | Comportamento Meu Documento | Comportamento Documento Público |
|---|---|---|
| DocRead | Ler e gravar no documento. As alterações feitas no documento não são refletidas em nenhum outro documento público. Modo: Leitura |
Leitura e gravação no documento. As alterações não são refletidas em nenhum outro documento público. Modo: Gravação |
| DocWrite | Ler e gravar no documento. As alterações são refletidas em todos os outros documentos públicos. Modo: Gravação |
Ler e gravar no documento. As alterações são refletidas em todos os outros documentos públicos. Modo: Gravação |
| DocRead, DocWrite | Ler e gravar no documento. As alterações são refletidas em todos os outros documentos públicos. Modo: Gravação |
Ler e gravar no documento. As alterações são refletidas em todos os outros documentos públicos. Modo: Gravação |
Observação
Observe que o token também inclui informações do usuário (consulte as linhas 7 a 9 acima). Você pode usar isso para aumentar as informações do usuário que estão automaticamente disponíveis para o código Fluid usando o recurso de público. Consulte Adicionando dados personalizados a tokens para obter mais informações.
O provedor de token
Cada solicitação para o Azure Fluid Relay deve ser assinada com um JWT válido. O Fluid delega a responsabilidade de criar e assinar esses tokens para provedores de token.
Um provedor de token é responsável por criar e assinar tokens que o @fluidframework/azure-client usa para fazer solicitações ao serviço do Azure Fluid Relay. Você deve fornecer sua própria implementação de provedor de token seguro. No entanto, o Fluid fornece um InsecureTokenProvider que aceita seu segredo de locatário, e, então, gera localmente e retorna um token assinado. Esse provedor de token é útil para teste, mas não pode ser usado em cenários de produção.
Um provedor de token seguro sem servidor
Uma opção para criar um provedor de token seguro é criar uma função do Azure sem servidor e expô-la como um provedor de token. Isso permite que você armazene a chave secreta do locatário em um servidor seguro. Em seguida, seu aplicativo chamaria a função do Azure para gerar tokens em vez de assiná-los localmente, como faz o InsecureTokenProvider. Para obter mais informações, confira Como gravar um TokenProvider com uma função do Azure.
Conectando a autenticação do usuário à autenticação do serviço Fluid
Os serviços Fluid autenticam chamadas de entrada usando um segredo compartilhado do cliente que não esteja vinculado a um usuário específico. A autenticação do usuário pode ser adicionada com base nos detalhes do seu serviço Fluid.
Uma opção simples para a autenticação do usuário seria simplesmente usar uma função do Azure como seu provedor de token e impor a autenticação do usuário como uma condição de obtenção de um token. Se um aplicativo tentar chamar a função, ele falhará, a menos que seja autenticado com o sistema de autenticação. Se você estiver usando o Microsoft Entra ID, por exemplo, poderá criar um aplicativo do Microsoft Entra para sua função do Azure e associá-lo ao sistema de autenticação da sua organização.
Nesse caso, o usuário entraria em seu aplicativo usando o Microsoft Entra ID, por meio do qual você obteria um token para usar para chamar sua função do Azure. A própria função do Azure se comporta da mesma forma, mas agora está acessível somente para pessoas que também se autenticaram com o Microsoft Entra ID.
Como a função do Azure agora é seu ponto de entrada para obter um token válido, somente os usuários que se autenticaram corretamente para a função serão capazes de fornecer esse token para o serviço do Azure Fluid Relay a partir de seus aplicativos cliente. Essa abordagem em duas etapas permite que você use seu próprio processo de autenticação personalizado em conjunto com o serviço do Azure Fluid Relay.