Cadastro e validação
Ativação é uma checagem funcional, não uma revisão de formulário
POST /admin/institutions/{id}/activate não só registra que uma instituição alega suportar DCR e publicar um JWKS. Ele faz duas chamadas de saída reais e só vira a instituição pra Active se as duas passarem.
Checagem de registro dinâmico de cliente
O Directory emite pra si mesmo um certificado de cliente de curta duração, cacheado, da própria CA (nunca exposto por nenhuma rota) e um software statement assinado, e então faz um POST mTLS real pro dcrRegistrationUri declarado pela instituição, seguindo o formato do RFC 7591 (Dynamic Client Registration). Uma resposta contendo um client_id é tratada como prova de que o endpoint de fato implementa DCR — não só que a URL resolve.
Checagem de JWKS
Um GET simples contra o jwksUri declarado precisa devolver um JWK Set não vazio. Esse é o mesmo material de chave que outros participantes usariam pra validar as requisições assinadas da instituição, então um JWKS inalcançável ou vazio reprova a validação.
Segurança das requisições de saída
As duas checagens passam por uma guarda de SSRF que resolve o host alvo e recusa endereços privados, loopback e link-local por padrão — uma instância do Directory é um chamador interno confiável do ponto de vista do que ela valida, então não pode ser usável como proxy aberto contra a própria rede do host. Isso pode ser relaxado por implantação em ecossistemas onde endpoints declarados legitimamente vivem em redes privadas.
Idempotência e novas tentativas
A ativação não tem cooldown nem efeito colateral além da transição de status — é seguro chamar de novo depois de corrigir um endpoint que estava falhando. Uma resposta com um array errors não vazio nomeia qual das duas checagens falhou.
Limitação de taxa
POST /register, POST /login e POST /password-reset são todos limitados por IP de origem (em memória por padrão, com Redis se a implantação precisar rodar mais de uma réplica) — independentemente uns dos outros, então esgotar um não afeta os demais.