Directory. / documentación técnica

Registro y validación

La activación es una verificación funcional, no una revisión de formulario

POST /admin/institutions/{id}/activate no solo registra que una institución afirma soportar DCR y publicar un JWKS. Hace dos llamadas salientes reales y solo cambia la institución a Active si ambas tienen éxito.

Verificación de registro dinámico de cliente

Directory se emite a sí mismo un certificado de cliente de corta duración, cacheado, de su propia CA (nunca expuesto por ninguna ruta) y un software statement firmado, y luego hace un POST mTLS real al dcrRegistrationUri declarado por la institución, siguiendo el formato de RFC 7591 (Dynamic Client Registration). Una respuesta que contenga un client_id se trata como prueba de que el endpoint realmente implementa DCR — no solo que la URL resuelve.

Verificación de JWKS

Un GET simple contra el jwksUri declarado debe devolver un JWK Set no vacío. Ese es el mismo material de clave que otros participantes usarían para validar las solicitudes firmadas de la institución, así que un JWKS inalcanzable o vacío reprueba la validación.

Seguridad de las solicitudes salientes

Ambas verificaciones pasan por una protección SSRF que resuelve el host de destino y rechaza direcciones privadas, loopback y link-local por defecto — una instancia de Directory es un llamador interno confiable desde la perspectiva de lo que valida, así que no debe poder usarse como proxy abierto contra la propia red de su host. Esto puede relajarse por implementación en ecosistemas donde los endpoints declarados viven legítimamente en redes privadas.

Idempotencia y reintentos

La activación no tiene tiempo de espera ni efectos secundarios más allá de la transición de estado — es seguro volver a llamarla después de corregir un endpoint que fallaba. Una respuesta con un array errors no vacío indica cuál de las dos verificaciones falló.

Limitación de tasa

POST /register, POST /login y POST /password-reset están todos limitados por IP de origen (en memoria por defecto, respaldado por Redis si la implementación necesita correr más de una réplica) — independientemente entre sí, así que agotar uno no afecta a los demás.