> ## Documentation Index > Fetch the complete documentation index at: https://docs.lerian.studio/llms.txt > Use this file to discover all available pages before exploring further. # Caradhras no Access Manager > Veja para que o Auth e o Identity usam o Caradhras, onde ficam os dados de identidade e quais variáveis apontam o Access Manager para ele. O Access Manager guarda os dados de identidade dele no Caradhras. O Identity e o Auth se conectam ao mesmo backend, cada um para um trabalho diferente. ## Para que cada serviço usa *** * **Identity** armazena no backend os usuários, grupos, applications, provedores de comunicação, vínculos entre application e provedor, e configuração de MFA. * **Auth** fica entre os seus produtos Lerian protegidos e o Caradhras. Ele encaminha os pedidos de token ao backend e valida com ele os refresh tokens. Ele também lê as claims do token que identificam o subject e o contexto de tenant. * **A aplicação no nível do produto** depende das claims que o Caradhras emite. Um token é interno quando carrega a claim `isInternal` com o valor `true`. O Caradhras emite essa claim apenas para applications que a plataforma provisiona como serviços internos da Lerian. O Caradhras guarda os dados de acesso. O Identity os escreve, o Auth os lê para decidir, e cada produto protegido age conforme a decisão. Por exemplo, o Identity cria um usuário e coloca esse usuário em um grupo de produto. O Auth então emite o access token e responde às verificações de permissão que vêm depois. ## Onde os dados ficam *** O Caradhras persiste esses dados no banco de dados PostgreSQL que você configura para o Access Manager. O PostgreSQL sustenta o Caradhras. Ele não o substitui. As mudanças de schema rodam como uma etapa de migração separada, nunca quando um serviço sobe. Os dois serviços alcançam o backend por HTTP no endereço que você configura. O Auth e o Identity precisam do backend acessível antes de subirem. O Helm chart do Access Manager faz o deploy do backend junto com os dois serviços. O Valkey guarda em cache os dados de token, de permissão e relacionados a MFA, para que o Auth repita menos chamadas ao backend durante a operação normal. ## Tokens e chaves *** Os access tokens emitidos para as applications que o Identity cria expiram depois de uma hora. As applications criadas fora do Identity têm o próprio tempo de vida. Quando a aplicação do controle está ligada, os tokens máquina a máquina são verificados contra as chaves de assinatura atuais do emissor, renovadas automaticamente. `AUTHORIZER_JWT_CERTIFICATE` guarda uma chave pública. Um backend de identidade novo gera o próprio par de chaves na primeira subida, e essa variável diz ao Access Manager em qual chave pública confiar. Um valor configurado mas inutilizável impede o serviço de subir. ## Configuração *** Quatro variáveis conectam o Access Manager ao Caradhras. * `AUTHORIZER_ADDRESS` dá o endereço do backend de identidade. Leia [Instalando o Access Manager](/pt/platform/access-manager/installing-access-manager). * `AUTHORIZER_JWT_CERTIFICATE` fornece a chave pública que valida os tokens que o backend de identidade emite. Leia [Helm chart do Access Manager](/pt/platform/deploy/access-manager/access-manager-helm). * `PLUGIN_AUTH_SSO_STATIC_ORGANIZATION` fixa o SSO pré-login em uma organização do Caradhras. Leia [Serviço Identity](/pt/platform/access-manager/identity-plugin). * `PLATFORM_INTERNAL_CIDRS` declara as redes a partir das quais os serviços da plataforma chamam o Caradhras. Quando uma lista de IPs permitidos do tenant está ativa, o Auth pode negar requisições da plataforma vindas de redes não listadas aqui. Leia [Lista de IPs permitidos do tenant](/pt/platform/access-manager/product-level-enforcement#tenant-ip-allowlist).