Adicione revendicações personalizadas para tokens de acesso JWT com o Logto para impulsionar sua autorização

Em artigos anteriores, mencionamos que cada vez mais sistemas estão utilizando tokens de acesso no formato JWT para autenticação de usuários e controle de acesso. Uma das razões importantes para isso é que o JWT pode conter algumas informações úteis, como funções e permissões do usuário. Essas informações podem nos ajudar a passar informações de identidade de usuário entre o servidor e o cliente, alcançando assim a autenticação de usuários e o controle de acesso.

Normalmente, as informações contidas no JWT são determinadas pelo servidor de autenticação. De acordo com o protocolo OAuth 2.0, o JWT geralmente contém campos como sub (sujeito), aud (audiência) e exp (tempo de expiração), que são comumente referidos como reivindicações. Essas reivindicações podem ajudar a verificar a validade do token de acesso.

No entanto, existem inúmeros cenários em que o JWT é utilizado para verificação, e as reivindicações comuns de JWT frequentemente podem não atender às necessidades do usuário. As pessoas geralmente pensam que, como o JWT pode conter algumas informações, podemos adicionar algumas informações a ele para facilitar a autorização?

A resposta é SIM, podemos adicionar reivindicações personalizadas ao JWT, como o escopo do usuário atual e o nível de assinatura. Dessa forma, podemos passar informações de identidade do usuário entre o cliente e o servidor (aqui referindo-se ao servidor que fornece vários serviços diferentes, também chamado de provedor de serviços), para alcançar a autenticação de usuários e o controle de acesso.

Para reivindicações padrão do JWT, consulte RFC7519. O Logto, como uma solução de identidade que suporta tanto autenticação quanto autorização, estendeu as reivindicações de recurso e escopo com base nisso para suportar RBAC padrão RBAC. Embora a implementação de RBAC do Logto seja padrão, ela não é simples e flexível o suficiente para se adequar a todos os casos de uso.

Com base nisso, o Logto lançou uma nova funcionalidade de personalização de reivindicações JWT, que permite que os usuários personalizem reivindicações adicionais ao JWT, para que a autenticação de usuários e o controle de acesso possam ser implementados de forma mais flexível.

Como funciona as reivindicações personalizadas JWT do Logto?#

Você pode acessar a página de listagem de JWT personalizados clicando no botão "JWT claims" na barra lateral.

Vamos começar adicionando reivindicações personalizadas para os usuários finais.

No editor à esquerda, você pode personalizar sua função getCustomJwtClaims. Este método possui três parâmetros de entrada: token, data e envVariables.

• token é o payload bruto do token de acesso obtido com base nas credenciais do usuário final atual e na configuração do seu sistema, e as informações de acesso do usuário no Logto.
• data é toda a informação sobre o usuário no Logto, incluindo todas as funções do usuário, identidades de login social, identidades de SSO, membros de organizações, etc.
• envVariables são as variáveis de ambiente que você configurou no Logto para o cenário de uso do token de acesso do usuário final atual, como chave(s) de API dos APIs externos necessários, etc.

Os cards à direita podem ser expandidos para mostrar a introdução dos parâmetros correspondentes, e você também pode configurar as variáveis de ambiente para o cenário atual aqui.

Após ler as introduções de todos os cards à direita, você pode mudar para o modo de teste, onde poderá editar os dados de teste e usar os dados de teste editados para verificar se o comportamento do script que você escreveu no editor de código à esquerda atende às suas expectativas.

Este é um diagrama de sequência mostrando o processo de execução da função getCustomJwtClaims quando um usuário final inicia uma solicitação de autenticação ao Logto e eventualmente obtém o token de acesso no formato JWT retornado pelo Logto.

Se a funcionalidade JWT personalizada não estiver ativada, a etapa 3 na figura será ignorada e a etapa 4 será executada logo após o término da etapa 2. Nesse momento, o Logto assumirá que o valor de retorno de getCustomJwtClaims será um objeto vazio, e então continuará a passar pelas etapas subsequentes.

Impulsione sua autorização com reivindicações JWT personalizadas: um exemplo prático#

Na seção anterior, apresentamos o princípio de funcionamento do JWT personalizado do Logto. Nesta parte, vamos mostrar como usar as reivindicações JWT personalizadas do Logto para melhorar a flexibilidade da autorização e o desempenho do provedor de serviços através de um exemplo real.

Configuração do cenário#

A equipe de John desenvolveu um App Assistente de IA que permite aos usuários conversar com robôs de IA para obter vários serviços.

Os serviços de robô de IA são divididos em serviços gratuitos e pagos. Os serviços gratuitos incluem recomendações especiais de tarifas aéreas, enquanto os serviços pagos incluem previsões de ações.

O App Assistente de IA usa o Logto para gerenciar todos os usuários, que são divididos em três tipos: usuários gratuitos, usuários pré-pagos e usuários premium. Usuários gratuitos podem usar apenas serviços gratuitos, usuários pré-pagos podem usar todos os serviços (cobrados por uso) e usuários premium podem usar todos os serviços (mas têm limites de taxa para evitar uso malicioso).

Além disso, o App Assistente de IA usa o Stripe para gerenciar pagamentos de usuários e possui seu próprio serviço de log para registrar logs de operações dos usuários.

Configurações do Logto#

Primeiro, criamos recursos de API para o serviço do App Assistente de IA e criamos dois escopos, recommend:flight e predict:stock.

Em seguida, criamos dois roles, free-user e paid-user, e atribuimos os escopos correspondentes:

• Atribua o escopo recommend:flight ao papel free-user.
• Atribua ambos os escopos recommend:flight e predict:stock ao papel paid-user.

Finalmente, criamos três usuários, free-user, prepaid-user e premium-user, e atribuímos os papéis correspondentes:

• Atribua o papel free-user ao usuário free-user.
• Atribua o papel paid-user aos usuários prepaid-user e premium-user.

Conforme mostrado na figura a seguir, para implementar as informações de autorização necessárias para o cenário descrito acima, esperamos incluir as informações de roles, balance e numOfCallsToday do usuário atualmente logado no JWT. Ao verificar o token de acesso no App Assistente de IA, essas informações podem ser usadas para rapidamente realizar a verificação de permissões.

Após configurar as envVariables, implementamos a função getCustomJwtClaims e clicamos no botão "Run test" para ver o resultado das reivindicações JWT extras com base nos dados de teste atuais.

Como não configuramos os dados de teste para data.user.roles, as roles mostradas no resultado são um array vazio.

Verifique se a funcionalidade do JWT personalizado está ativada#

De acordo com a configuração do Logto acima, obtivemos os resultados correspondentes no teste. Em seguida, vamos usar o app de amostra fornecido pelo Logto para verificar se nosso JWT personalizado está funcionando. Encontre o SDK com o qual você está familiarizado em Logto SDKs e implante um app de amostra de acordo com a documentação e o repositório correspondente no GitHub.

Com base na configuração que descrevemos acima, levando o React SDK como exemplo, precisamos atualizar a configuração correspondente no LogtoConfig:

Após fazer o login do usuário free_user no app de amostra que simula o App Assistente de IA, podemos ver as informações de roles, balance, numOfCallsToday, isPaidUser e isPremiumUser que adicionamos visualizando a parte do payload do token de acesso JWT.

Os valores de balance, numOfCallsToday, isPaidUser e isPremiumUser são consistentes com o teste anterior, e roles é igual a ["free-user"]. Isso porque, no processo real de login do usuário final, obteremos todos os dados acessíveis do usuário e os processaremos de acordo.

Para usuários premium, podemos ver que roles é ["paid-user"] e tanto isPaidUser quanto isPremiumUser são true.

Atualize a lógica de autorização do provedor de serviços#

Nos passos anteriores, adicionamos reivindicações personalizadas com base nas necessidades de negócios ao token de acesso de usuário. Em seguida, podemos usar essas reivindicações para realizar a verificação de autorização rapidamente.

Aqui fornecemos a lógica do Logto para verificar tokens de acesso JWT no lado da API. A implementação completa do código pode ser encontrada no repositório do GitHub:

Você pode se referir à lógica da API do Logto para verificar tokens de acesso e personalizá-la de acordo com sua própria lógica de negócios. Por exemplo, para o cenário do App Assistente de IA descrito aqui, você pode adicionar a lógica de verificação para reivindicações personalizadas como roles, balance, numOfCallsToday, isPaidUser e isPremiumUser na função verifyBearerTokenFromRequest.

O exemplo acima é para o cenário em que afeta o login do usuário final e a obtenção do token de acesso JWT. Se seu caso de uso for máquina a máquina (M2M), você também pode configurar reivindicações personalizadas JWT para aplicativos M2M separadamente.

Configurar JWT personalizados para usuários não afetará o resultado de aplicativos M2M obtendo tokens de acesso, e vice-versa.

Devido à generalidade das conexões M2M, o Logto atualmente não fornece a função do método getCustomJwtClaims de aplicativos M2M para aceitar dados internos do Logto. Em outros aspectos, o método de configuração de JWT personalizados para aplicativos M2M é o mesmo que para aplicativos de usuários. Este artigo não detalhará sobre isso. Você pode usar a função de JWT personalizados do Logto para começar.

Por que usar reivindicações JWT personalizadas?#

Fornecemos o cenário do App Assistente de IA para John e como usar a funcionalidade de JWT Personalizado do Logto para alcançar uma verificação de autorização mais flexível. Nesse processo, podemos ver as vantagens da funcionalidade JWT Personalizado:

1. Sem a funcionalidade JWT Personalizado, os usuários precisam solicitar uma API externa (como o que você faz em getCustomJwtClaims) toda vez que verificam permissões. Para o provedor de serviços que fornece essa API, isso pode aumentar a carga extra. Com a funcionalidade JWT Personalizado, essas informações podem ser colocadas diretamente no JWT, reduzindo as chamadas frequentes à API externa.
2. Para provedores de serviços, a funcionalidade JWT Personalizado pode ajudá-los a verificar as permissões do usuário mais rapidamente, especialmente quando o cliente chama o provedor de serviços com frequência, melhorando o desempenho do serviço.
3. A funcionalidade JWT Personalizado pode ajudá-lo a implementar rapidamente as informações adicionais de autorização exigidas pelo negócio, e as informações podem ser transmitidas entre o cliente e o provedor de serviços de maneira segura, uma vez que o JWT é auto-contido e pode ser criptografado, tornando difícil sua falsificação.

Ao mesmo tempo, uma vez que o getCustomJwtClaims é executado toda vez que um usuário precisa que o Logto emita um token de acesso, é necessário evitar executar lógicas excessivamente complexas e solicitações de APIs externas com alto requisito de largura de banda. Caso contrário, pode demorar muito para os usuários finais esperarem o resultado de getCustomJwtClaims durante o processo de login. Se o seu getCustomJwtClaims retornar um objeto vazio, recomendamos fortemente que você exclua temporariamente este item de configuração até que você realmente precise usá-lo.

Conclusão#

Neste artigo, o Logto estendeu o token de acesso JWT básico e estendeu a funcionalidade de reivindicações JWT extras para permitir que os usuários coloquem informações adicionais do usuário final no token de acesso JWT de acordo com suas necessidades de negócios, para que, após o usuário se logar, as permissões do usuário possam ser verificadas rapidamente.

Fornecemos o cenário do App Assistente de IA de John e demonstramos como usar a funcionalidade JWT Personalizado do Logto para alcançar uma verificação de autorização mais flexível. Também apontamos alguns pontos-chave ao usar o JWT personalizado. Em combinação com cenários de negócios reais, os usuários podem inserir várias informações relacionadas ao usuário no token de acesso JWT de acordo com suas necessidades de negócios, permitindo que o provedor de serviços verifique rapidamente as permissões do usuário.