Autenticação e autorização em seu aplicativo
A segurança é fundamental para as aplicações Web modernas. O Fluid Framework, como parte da arquitetura da sua aplicação Web, é uma parte importante da infraestrutura a proteger. O Fluid Framework é uma arquitetura em camadas, e os conceitos relacionados à auth são implementados com base no serviço Fluid ao qual ele está se conectando. Isso significa que, embora existam temas de autenticação comuns em todos os serviços do Fluid, os detalhes e as especificidades serão diferentes para cada serviço.
Serviço Azure Fluid Relay
A cada locatário do serviço Azure Fluid Relay que você cria é atribuída uma ID de locatário e sua própria chave secreta de locatário exclusiva.
A chave secreta é um segredo partilhado. Seu aplicativo/serviço sabe disso, e o serviço Azure Fluid Relay sabe disso. Como a chave secreta do locatário está exclusivamente vinculada ao seu locatário, usá-la para assinar solicitações garante ao serviço 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 Azure Fluid Relay sabe que as solicitações estão vindo do seu aplicativo ou serviço. Isso é fundamental, porque uma vez que o serviço Azure Fluid Relay pode confiar que é seu aplicativo fazendo as solicitações, ele pode confiar nos dados que você envia. É também por isso que é importante que o segredo seja tratado de forma segura.
Atenção
Qualquer pessoa com acesso ao segredo pode representar seu aplicativo ao se comunicar com o serviço Azure Fluid Relay.
Tokens Web JSON e serviço Azure Fluid Relay
O Azure Fluid Relay usa JSON Web Tokens (JWTs) para codificar e verificar dados assinados com sua chave secreta. JSON Web Tokens são um bit assinado de JSON que pode incluir informações adicionais sobre direitos e permissões.
Nota
As especificidades dos JWTs estão além do escopo deste artigo. Para obter mais informações sobre o padrão JWT, consulte Introdução aos Web Tokens JSON.
Embora os detalhes da autenticação sejam diferentes entre os serviços do Fluid, vários valores devem estar sempre presentes.
- containerId O serviço Fluid precisa do ID do contêiner para identificar qual serviço corresponde ao contêiner de chamada. Nota: O JWT chama esse campo documentId, mas o serviço Fluid espera um ID de contêiner nesse campo.
- tenantId: O serviço Azure Fluid Relay usa a ID do locatário para recuperar o segredo compartilhado que ele usará para autenticar sua solicitação.
- escopos: 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 visto no connections campo em AzureAudience. As permissões de escopo de token podem ser atualizadas em sua Função do Azure sem servidor sob a generateToken função.
const token = generateToken(
tenantId,
documentId,
key,
scopes ?? [ "Token Scope" ],
user
);
Os escopos de token, juntamente com o comportamento e os modos do contêiner, são os seguintes:
| Escopo do token | Comportamento do meu documento | Comportamento do documento de audiência |
|---|---|---|
| DocRead | Leia e escreva no documento. As alterações feitas no documento não são refletidas em nenhum outro documento de audiência. Modo: Ler |
Ler e escrever no documento. Alterações não refletidas em nenhum outro documento de audiência. Modo: Escrever |
| DocWrite | Leia e escreva no documento. As alterações feitas são refletidas em todos os outros documentos de audiência. Modo: Escrever |
Leia e escreva no documento. As alterações feitas são refletidas em todos os outros documentos de audiência. Modo: Escrever |
| DocRead, DocWrite | Leia e escreva no documento. As alterações feitas são refletidas em todos os outros documentos de audiência. Modo: Escrever |
Leia e escreva no documento. As alterações feitas são refletidas em todos os outros documentos de audiência. Modo: Escrever |
Nota
Observe que o token também inclui informações do usuário (veja as linhas 7-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 audiência . Consulte Adicionando dados personalizados a tokens para obter mais informações.
O provedor de token
Cada solicitação ao Azure Fluid Relay deve ser assinada com um JWT válido. A Fluid delega a responsabilidade de criar e assinar esses tokens a provedores de tokens.
Um provedor de token é responsável por criar e assinar tokens que o @fluidframework/azure-client usa para fazer solicitações ao serviço Azure Fluid Relay. Você é obrigado a fornecer sua própria implementação de provedor de token seguro. No entanto, o Fluid fornece um que aceita seu segredo de InsecureTokenProvider locatário e, em seguida, gera e retorna localmente um token assinado. Esse provedor de token é útil para testes, 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. Seu aplicativo chamaria a Função do Azure para gerar tokens em vez de assiná-los localmente como o InsecureTokenProvider faz. Para obter mais informações, consulte Como escrever um TokenProvider com uma função do Azure.
Conectando a autenticação do usuário à autenticação de serviço Fluid
Os serviços fluidos autenticam chamadas recebidas usando um segredo de cliente compartilhado, que não está 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 autenticação de usuário seria simplesmente usar uma Função do Azure como seu provedor de token e impor a autenticação do usuário como condição para obter um token. Se um aplicativo tentar chamar a função, ele falhará, a menos que seja autenticado com seu sistema de autenticação. Se você estiver usando o Microsoft Entra ID, por exemplo, poderá criar um aplicativo Microsoft Entra para sua Função do Azure e vinculá-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 só é acessível a 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 na Função poderão fornecer esse token ao serviço Azure Fluid Relay a partir de seu aplicativo cliente. Essa abordagem de duas etapas permite que você use seu próprio processo de autenticação personalizado em conjunto com o serviço Azure Fluid Relay.