PMQ.Identity

538 downloads · 28 arquivos, 1.488 linhas · repositório

Módulo de identidade agnóstico de provedor. Dois modos: externo, com token de um provedor central por OIDC, e local, com JWT emitido pela própria aplicação.

O problema

A aplicação pequena começa emitindo o próprio token, porque é o caminho mais curto. Quando a empresa padroniza num provedor de identidade central, cada aplicação precisa ser reescrita na parte de autenticação, e essa parte está espalhada por todo lugar que lê usuário.

Eu vivi os dois lados dessa migração num parque com centenas de aplicações em estágios diferentes, e é de lá que vem o desenho.

A decisão

O modo é configuração, não arquitetura. A aplicação trabalha com uma abstração de identidade, e se o token vem de um provedor externo ou é emitido localmente fica num IdentityMode com dois caminhos de configuração isolados, ExternalSettings e LocalSettings, cada um com o seu IdentitySetup. Trocar um pelo outro deixa de ser reescrita e passa a ser uma linha.

O que isso resolve na prática: uma aplicação nova nasce em modo local, sem depender de ninguém provisionar cliente no provedor central; quando a padronização chega, ela troca de modo sem que nenhum código que lê usuário mude.

Mapeamento de claim configurável. Provedor de identidade não concorda sobre o nome da claim que carrega papel, identificador ou tenant, e cada um resolve de um jeito. Deixar esse mapa em configuração, o ClaimsMappingOptions, evita que trocar de provedor obrigue a caçar string mágica espalhada pelo código.

O limite

O modo local existe para o caminho curto e para desenvolvimento, não para ser um provedor de identidade. Ele emite e valida JWT; não faz federação, não gerencia consentimento, não rotaciona chave sozinho. Aplicação que precisa disso deve usar um provedor de verdade, que é exatamente o que o modo externo espera.