Descoberta OIDC e JWKS — API

Expõe os metadados OpenID Connect do servidor de autorização e o conjunto de chaves públicas usado para validar a assinatura dos tokens. As duas rotas são públicas, globais (não há mais conceito de tenant) e não têm efeito colateral.

A antiga rota GET /redirect (redirect padrão por tenant) não existe mais — não há ocorrência dela no código atual. O redirect de entrada do fluxo de autorização hoje é resolvido por IDENTITY_OAUTH_BROWSER_AUTHORIZATION_START_URL, usado pelo GET /oauth/authorize (ver Autorizar aplicação).

Funcionamento

GET /.well-known/openid-configuration: monta o documento de discovery a partir de valores de configuração (issuer e as bases de URL do próprio serviço) — sem consulta a banco.

GET /.well-known/jwks.json: lê as chaves públicas RSA ativas (para validar assinatura RS256) e devolve o conjunto. É global — todo o Identity usa uma única chave de assinatura ativa por vez, não há particionamento por tenant ou organização.

Endpoints

Método	Rota	Descrição
GET	/v1/.well-known/openid-configuration	Documento de discovery OIDC
GET	/v1/.well-known/jwks.json	Conjunto de chaves públicas (JWKS)

Versão: v1

Swagger:

• GET /.well-known/openid-configuration
• GET /.well-known/jwks.json

Rota (Dev): http://localhost:3000/v1/.well-known/openid-configuration

Lógica de decisão das duas rotas:

Nenhuma das duas rotas tem ramificação de erro de negócio conhecida — ambas são leitura pura de configuração/chaves já carregadas.

Permissões

Rota	Guards	Acesso
GET /.well-known/openid-configuration	nenhum	Público
GET /.well-known/jwks.json	nenhum	Público

Headers

Nenhum header exigido.

Path parameters

Nenhum — não há mais tenant no path.

Query parameters

Nenhum.

Body

Não se aplica (rotas GET sem corpo).

Response

200 — openid-configuration (IdentityOpenIdConfigurationResponse):

json
{
  "issuer": "http://localhost:3000",
  "authorization_endpoint": "http://localhost:3000/v1/oauth/authorize",
  "token_endpoint": "http://localhost:3000/v1/oauth/token",
  "introspection_endpoint": "http://localhost:3000/v1/oauth/introspect",
  "userinfo_endpoint": "http://localhost:3000/v1/userinfo",
  "jwks_uri": "http://localhost:3000/v1/.well-known/jwks.json",
  "response_types_supported": ["code"],
  "code_challenge_methods_supported": ["S256"],
  "grant_types_supported": ["authorization_code", "client_credentials", "refresh_token"],
  "subject_types_supported": ["public"],
  "id_token_signing_alg_values_supported": ["RS256"],
  "token_endpoint_auth_methods_supported": ["none", "client_secret_post"]
}

Este documento tem 11 campos e o DTO de resposta espelha exatamente todos eles — não há divergência entre o que o serviço monta e o que o Swagger anuncia.

200 — jwks.json:

json
{ "keys": [{ "kty": "RSA", "use": "sig", "kid": "<key-id>", "alg": "RS256", "n": "<módulo RSA>", "e": "AQAB" }] }

Erros

Não há erro de negócio conhecido nestas rotas — nenhuma exceção específica foi identificada neste levantamento.

Regras de negócio

ID	Regra	Comportamento
RN-01	Só PKCE S256 é anunciado	code_challenge_methods_supported: ['S256']
RN-02	JWKS é global, não por tenant	uma única chave de assinatura ativa vale para todo o Identity
RN-03	Só authorization_code, client_credentials e refresh_token são anunciados	reflete exatamente os grants aceitos em /oauth/token — não há mobile_credentials/verify_qrcode_login
RN-04	revocation_endpoint, end_session_endpoint, scopes_supported e claims_supported não existem	não é uma omissão do DTO frente ao código — o serviço de metadados simplesmente não os gera; essas capacidades (revogação RFC 7009, logout OIDC padrão, catálogo de escopos/claims) não estão implementadas

Compliance

Órgão / norma	Exigência	Como a rota atende
OIDC / OAuth 2.0	metadados de discovery e JWKS padronizados	ambas seguem os campos previstos pela especificação, dentro do que está implementado
LGPD	sem dados pessoais	apenas metadados públicos e chaves públicas
HIPAA	integridade dos tokens verificável	chave pública RS256 exposta para validação de assinatura

Variáveis de ambiente

Variável	Uso	Default
IDENTITY_OAUTH_ISSUER	issuer do discovery e claim iss assinada/verificada	http://localhost:3000

As demais URLs do documento (authorization_endpoint, token_endpoint etc.) são montadas a partir do próprio issuer mais o caminho fixo de cada rota — não têm variáveis próprias.

Tempo médio de resposta

A confirmar — responsável: time de Identity; data: 24/09/2026. Sem medição publicada.

Requisitos não funcionais

Requisito	Definição
Idempotência	Sim — leitura pura, sem efeito colateral
Rate limit	Não identificado @Throttle específico nestas rotas
Cache	Não há cache explícito no código — ambas são boas candidatas
Auditoria	Não — apenas leitura de metadados públicos

Divergências e lacunas confirmadas

• A antiga rota GET /redirect (por tenant) foi removida; não há fallback genérico de tenant porque o próprio conceito de tenant no path deixou de existir neste módulo.
• Não há revocation_endpoint nem end_session_endpoint no discovery, porque essas capacidades (RFC 7009 e logout OIDC padrão) não estão implementadas — ver Token e Encerrar sessão para o que existe no lugar delas.

Relacionado

• 📂 Módulo: Authentication
• 🔁 Token — token_endpoint e introspection_endpoint anunciados aqui
• 🔑 Autorizar aplicação (OAuth) — authorization_endpoint anunciado aqui