Pega metadatos del proveedor, no secretos o tokens de producción. Se revisan declaraciones sin contactar al proveedor ni confirmar registro o redirecciones permitidas.
Se ejecuta localmente en tu navegadorUtiliza Authorization Code con PKCE en clientes web y móviles. Este comprobador local no confirma el registro en el proveedor, las listas permitidas de redirect URI, la política de consentimiento ni el comportamiento real de los tokens.
Pega el JSON que devuelve /.well-known/openid-configuration, pulsa Inspeccionar configuración OIDC y lee los hallazgos: la página nombra los campos de los que depende un cliente público con Authorization Code y separa los problemas bloqueantes de los puntos a revisar. Los campos de client ID y redirect URI son opcionales y solo hacen más concreta esa revisión local.
El botón PKCE toma 48 bytes aleatorios, los resume con SHA-256 y muestra el verificador de código, el desafío S256 y un valor state. Todo ocurre en esta pestaña mediante la API Web Crypto; los metadatos que pegas no se envían ni a VoriTools ni al proveedor de identidad.
El inspector lee los campos de los que depende un cliente de navegador o móvil: issuer, authorization_endpoint y token_endpoint deben ser URL absolutas —HTTPS en producción y HTTP solo en direcciones de bucle local— y jwks_uri debe anunciarse para poder verificar las firmas de los tokens. response_types_supported tiene que incluir code y grant_types_supported tiene que incluir authorization_code para el flujo Authorization Code.
El campo con más peso en un cliente público es code_challenge_methods_supported. Sin PKCE, un código de autorización capturado en un móvil o mediante un esquema de URL propio puede canjearlo quien lo intercepte, así que un anuncio que solo ofrece plain, o que omite el campo, se trata aquí como bloqueante y no como aviso.
Generar conjunto PKCE toma 48 bytes aleatorios de crypto.getRandomValues, los codifica en base64url y muestra el verificador de 64 caracteres. El desafío S256 es el base64url del resumen SHA-256 de ese verificador —43 caracteres— y el valor state son 24 bytes aleatorios, 32 caracteres, que se comparan cuando el proveedor devuelve la redirección con el código.
Usa S256: el desafío viaja en la petición de autorización, el verificador se queda en tu cliente hasta la petición de token y un código capturado entre ambas no se puede canjear. El método plain envía el propio verificador en la URL; por eso un documento que solo admite plain termina esta inspección con un hallazgo bloqueante.
El documento se lee tal cual se pega. La página no puede saber si el proveedor registró tu cliente, si el redirect URI está en su lista permitida, qué pantalla de consentimiento ve el usuario ni si los endpoints se comportan como anuncian; eso exige una petición de autorización real contra el proveedor.
Un resultado sin hallazgos significa que los metadatos copiados son coherentes para un cliente público, no que la integración funcione. Los flujos reales, la vida de los tokens y la renovación aún deben probarse contra el proveedor, y la comprobación del redirect URI aquí es solo un recordatorio local de coincidencia exacta.