ID Uruguay: integración con OpenID Connect
Objetivo
El objetivo de este documento es brindar una descripción detallada de cómo funciona el protocolo OpenID Connect 1.0 en ID Uruguay y cómo es posible operar como un cliente de este para obtener información verificada de la ciudadanía de manera segura, tanto para la aplicación cliente como para los usuarios.
Terminología
La terminología utilizada en este documento responde a la detallada por las especificaciones de OpenID Connect 1.0 y OAuth 2.0. No obstante, se brindarán definiciones para algunos términos fundamentales como "roles", "claims", "scopes" y "tokens".
¿Qué es ID Uruguay?
Es la plataforma de autenticación implementada por Agesic para centralizar cuentas de usuarios y facilitar el acceso web a los servicios digitales del Estado. Esto quiere decir que, una vez registrado en ID Uruguay, un usuario podrá ingresar a los servicios vinculados a la cuenta sin necesidad de nuevos registros ni contraseñas adicionales.
¿Qué es OpenID Connect 1.0?
Es un protocolo de identidad simple y de estándar abierto creado sobre el protocolo OAuth 2.0, el cual permite a aplicaciones Cliente (Relaying Party) verificar la identidad de un usuario basado en la autenticación realizada por este en un Servidor de Autorización (OpenID Provider), así como también obtener información personal del usuario mediante el uso de una API REST.
¿Por qué OpenID Connect 1.0 en ID Uruguay?
OpenID Connect 1.0 es un protocolo que se encuentra implementado en múltiples lenguajes de programación y está siendo utilizado por la mayoría de los sitios y aplicaciones que requieren el manejo de un usuario, existiendo muchos proveedores (Google, Facebook, Linkedin, etc) y aún muchos más Clientes.
Su principal funcionalidad es permitir a usuarios de un sitio (Cliente) iniciar sesión o registrarse autenticándose en otro sitio (OpenID Provider) que ya contiene sus datos.
Entre sus principales ventajas se encuentran:
Acelera el proceso de registro
La mayoría de los portales del Estado (y otros sitios) solicitan a sus usuarios que completen un formulario de registro con información que, por lo general, comprende el mismo conjunto de datos (primer nombre, primer apellido, correo electrónico, etc.). Con OpenID Connect, los usuarios pueden proveer esta información con un solo clic. De este modo, el proceso de registro es más simple, rápido y seguro.
Reduce la frustración de administrar diferentes contraseñas
La mayoría de los usuarios que utilizan servicios web deben recordar diferentes nombres de usuario y contraseñas para iniciar sesión en cada uno de ellos. Recordar estas combinaciones puede ser una tarea muy tediosa, pero utilizar las mismas credenciales implica un problema de seguridad importante. Con OpenID Connect, es posible iniciar sesión o registrarte en todos estos sitios manteniendo solo una cuenta (la de ID Uruguay).
Mejora el control sobre la identidad electrónica
Cada vez que un usuario inicia sesión en un aplicación externa utilizando OpenID Connect, deberá dar su consentimiento explícito de qué datos quiere compartir con la aplicación. De este modo, su cuenta ID Uruguay servirá como una identidad centralizada que podrá utilizarse de manera controlada en muchos sitios de internet.
Minimiza los riesgos de seguridad asociados a las contraseñas
Muchos usuarios utilizan la misma contraseña en múltiples sitios. De este modo, si alguno de estos fuera atacado y las contraseñas quedaran comprometidas, un hacker podría obtener acceso a todos los sitios que comparten esta credencial. Con OpenID Connect, si ocurriera una situación que comprometa las credenciales, basta con restablecer la contraseña en un lugar, ID Uruguay.
Roles del flujo de autenticación OpenID Connect 1.0
Los roles que participan en un flujo de autenticación OpenID Connect 1.0 son los siguientes:
- End-User: Participante humano capaz de autorizar el acceso a un recurso protegido validando su identidad.
- Relaying Party (RP): Aplicación Cliente que solicita la autenticación de un End-User a un OpenID Provider con el fin de poder acceder a recursos protegidos en nombre del usuario autenticado. En este caso, será la aplicación web/mobile que quiere integrarse con ID Uruguay para obtener información del usuario (claims).
- OpenID Provider (OP): Servidor de autenticación capaz de autenticar usuarios y proveer información sobre estos y el proceso de autenticación a un Relying Party. En este caso, será ID Uruguay.
Descripción general
En términos generales, el protocolo OpenID Connect 1.0 en ID Uruguay se puede describir a través de los pasos listados a continuación:
1. Un Cliente registrado (RP) envía un pedido de autenticación a ID Uruguay (OP).
2. El OP autentica al usuario y obtiene su autorización para compartir ciertos datos (claims) con el RP.
3. El OP responde con un ID Token y un Access Token al RP.
4. El RP utiliza el Access Token para solicitar información sobre el usuario al UserInfo Endpoint.
5. El UserInfo Endpoint retorna un listado de claims del usuario.
Finalmente, la aplicación Cliente (RP) podrá crear una sesión para el usuario autenticado o registrarlo en su base de datos con los claims obtenidos.
* NOTA: La autenticación en OpenID Connect puede llevarse a cabo de tres formas: Authorization Code Flow, Implicit Flow o Hybrid Flow. El mecanismo seleccionado determina como el ID Token y Access Token son retornados al Cliente y esto puede hacer que ciertos pasos sean modificados y/o nuevos pasos añadidos. En particular en ID Uruguay se implementa el Authorization Code Flow, que será descrito en detalle más adelante.
Tokens
En esta sección se presentan los diferentes tokens que participan en el proceso de autenticación y autorización de OpenID Connect 1.0 y, por lo tanto, en la implementación de ID Uruguay.
ID token
Un ID token es un JSON Web Token (JWT) que contiene información sobre el proceso de autenticación del End-User en el servidor de autenticación (OP).
Access token
Los Access tokens son credenciales emitidas por el servidor de autenticación (OP) para un cliente (RP) y tienen como fin permitirles el acceso a recursos protegidos. Un Access Token es un string opaco que representa el acceso a ciertos datos y puede ser utilizado por un tiempo limitado.
Refresh token
Los Refresh tokens son credenciales emitidas por el servidor de autenticación (OP) para un cliente (RP) y tienen como fin la obtención de nuevos Access tokens cuando estos expiran o se vuelven inválidos.
Claims y Scopes
Los JWT contienen claims, campos de información (tales como nombre o e-mail) sobre una entidad (típicamente un usuario) y metada adicional.
OpenID Connect 1.0 define un conjunto standard de claims, que incluyen nombre, correo electrónico y género, entre otros. Y los agrupa en scopes, que permiten a un RP definir qué tipo de información desea obtener sobre un usuario.
Por su parte, ID Uruguay toma como base los claims y scopes de OpenID Connect 1.0 y define los siguientes, que podrán ser solicitados en un Authentication Request:
| Nombre | Claims | Descripción |
|---|---|---|
| personal_info | nombre_completo, primer_nombre, segundo_nombre, primer_apellido, segundo_apellido, uid, rid | Nombres y apellidos del usuario, identificador y el nivel de registro de identidad digital. Este último puede ser alguno de los siguientes valores: [0,1,2,3] correspondiendo a los niveles Muy Bajo, Bajo, Medio y Alto, respectivamente. |
| profile | name, given_name, family_name | Nombre completo, nombre(s) y apellido(s) respectivamente. |
| document | pais_documento, tipo_documento, numero_documento | Información sobre el documento del usuario. |
| email, email_verified | Correo electrónico y si el mismo está verificado. | |
| auth_info | rid, nid, ae | Datos de registro y autenticación del ciudadano en formato URN correspondientes a la Política de Identificación Digital. |
De este modo, un RP podrá obtener los datos incluidos en los scopes que solicite, previa autorización del End-User (propietario de dichos datos).
* NOTA: El scope "profile" presenta información de nombres y apellidos del ciudadano de manera distinta a "personal_info". Este scope puede ser de ayuda para usar integraciones standard. Si se necesita la información del ciudadano en forma más modular, se recomienda usar el scope "personal_info".
ACR - Authentication Context Class reference
Authentication Context Class corresponde a un conjunto de métodos o procedimientos de autenticación que se consideran equivalentes entre sí en un contexto particular.
Los valores acr definidos en ID Uruguay son: "urn:iduruguay:nid:0, urn:iduruguay:nid:1, urn:iduruguay:nid:2 y urn:iduruguay:nid:3". Estos valores se corresponden con los niveles de seguridad en la identidad digital de la Política de Identificación Digital. Los nid son una correspondencia entre el RID del usuario en gub.uy (procedimiento de registro de identificación digital) y el AE utilizado (proceso de autenticación electrónica).
La solicitud de acr_values se realiza en la Authentication request y el acr satisfecho por el OP al autenticar al usuario es retornado en el ID Token. De no haber sido posible cumplir con lo solicitado, igualmente se retornará el acr satisfecho.
Si el (Relaying Party) envía un acr que no se corresponde a ninguno de los mencionados anteriormente, el OP responderá a la authentication request con error "invalid_request" y error_description "The request is otherwise malformed".
AMR - Authentication Methods References
Authentication Methods References es un JSON array of strings que corresponden a identificadores de métodos de autenticación usados en la autenticación.
Estos valores son retornados al (Relaying Party) en el ID Token.
Los valores amr definidos en ID Uruguay son: "urn:iduruguay:am:password, urn:iduruguay:am:totp, urn:iduruguay:am:ci, urn:iduruguay:am:idp:ae:0, urn:iduruguay:am:idp:ae:1, urn:iduruguay:am:idp:ae:2, urn:iduruguay:am:idp:ae:3".
Los valores con formato "urn:iduruguay:am:idp:ae:X" indican que el usuario se autenticó utilizando un Proveedor de Identidad, y los métodos que utilizó se corresponden con el AE (proceso de autenticación electrónica) X.
Integración OpenID Connect con ID Uruguay
El objetivo de esta sección es describir el procedimiento para registrarse y poder operar como Relaying Party en el proceso de autenticación/autorización OpenID Connect 1.0 de ID Uruguay
Registro como Cliente (Relaying Party)
Para ser dado de alta en el servicio se debe de llenar un formulario para poder generar el "partnership" entre el RP y el OP y enviarlo a soporte@agesic.gub.uy con copia a identificacion.electronica@agesic.gub.uy .
Hay un formulario de Testing y uno de Producción.
El formulario tiene dos secciones. La primera es de datos sobre la solicitud y contacto para eventuales notificaciones; y la segunda contiene datos técnicos.
Una vez entregado el formulario testing, se te proveerá de un ID y un Secret para que puedas autenticarte contra el servidor y comenzar a hacer pruebas.
Autenticación utilizando Authorization Code Flow
El Authorization Code Flow es uno de los tres posibles flujos de autenticación provistos por el protocolo OpenID Connect 1.0. En este, un RP redirige al End-User al Authorization Endpoint del OP, el cual lleva a cabo su autenticación y autorización. Si el resultado es exitoso, el OP retorna al RP un Authorization Code, que podrá ser utilizado (dentro de un período de tiempo) para obtener un ID Token y Access Token desde el Token Endpoint. Finalmente, el Access Token obtenido puede ser utilizado para conseguir claims sobre el usuario en el Userinfo Endpoint. El diagrama a continuación ilustra el flujo descrito.
* NOTA: Este flujo de autenticación tiene como beneficio que ningún token se encuentra expuesto al User Agent y, de este modo, a posibles aplicaciones maliciosas que lo controlen. Por ello, es apropiado para Clientes que puedan mantener de manera segura una clave secreta, típicamente aplicaciones con un Backend de datos.
Authorization Endpoint (/oidc/v1/authorize)
El Authorization Endpoint lleva a cabo la autenticación y autorización del End-User. Para invocarlo se debe enviar un Authentication request, que será respondido por un Authentication response. Ambos pedidos son detallados a continuación.
Authentication request
Un Authentication request es un pedido HTTP con ciertos parámetros que sirve para solicitar la autenticación de un End-User en ID Uruguay.
Este pedido puede llevarse a cabo empleando los métodos HTTP GET o HTTP POST definidos en el RFC 2616. Si se utiliza el método HTTP GET, los parámetros deberán ser serializados empleando URI Query String Serialization. En caso de utilizar el método HTTP POST, los parámetros deberán ser serializados utilizando Form Serialization.
A continuación, se muestra una tabla con los parámetros aceptados y una breve descripción de cada uno:
| Parámetro | Tipo | Descripción |
|---|---|---|
| scope | Requerido | Siempre debe incluirse "openid". Adicionalmente, se pueden incluir los scopes descritos en la sección "Claims y Scopes" separados por espacios. Ej: "openid personal_info email". |
| response_type | Requerido | Valor que determina el tipo de flujo de autenticación a utilizar. En caso del Authorization Code Flow, es valor es "code". |
| client_id | Requerido | Identificador del cliente provisto al momento del registro. |
| redirect_uri | Requerido | URI a donde debe ser enviada la respuesta. Esta debe ser una de las registradas al momento de darse de alta como cliente. |
| state | Recomendado | Valor opaco para mantener el estado entre el pedido y la respuesta. Será retornado al cliente junto con el código de autorización o error |
| nonce | Opcional | String opaco utilizado para asociar la sesión de un Cliente con un ID Token y mitigar replay attacks. |
| prompt | Opcional | Lista de valores de cadena ASCII delimitados por un espacio, sensibles a minúsculas y mayúsculas, que especifica si el servidor de autorización solicita al usuario final la reautenticación y consentimiento. Los valores definidos son: `none, login y consent.` |
| acr_values | Opcional | Lista de strings sensibles a minúsculas y mayúsculas, separados por espacios y en orden de preferencia, correspondientes a los nombrados en la sección "acr - Authentication Context Class Reference". |
Ejemplo de Authentication request con HTTP GET
El RP retornará un HTTP 302 Redirect.
HTTP/1.1 302 Found
Location: https://auth-testing.iduruguay.gub.uy/oidc/v1/authorize?
response_type=code
&scope=openid%20personal%20email
&client_id=ID_CLIENTE
&state=STRING_RANDOM
&redirect_uri=https%3A%2F%2Fclient.org%2F
El navegador realiza el pedido:
GET /oidc/v1/authorize?
response_type=code
&scope=openid%20personal%20email
&client_id=ID_CLIENTE
&state=STRING_RANDOM
&redirect_uri=https%3A%2F%2Fclient.org%2F
Host: https://auth-testing.iduruguay.gub.uy
Ejemplo de Authentication request con HTTP POST
POST /oidc/v1/authorize HTTP/1.1 Host: auth-testing.iduruguay.gub.uy Content-Type: application/x-www-form-urlencoded response_type=code&scope=openid%20personal%20email&client_id=ID_CLIENTE&state=STRING_RANDOM&redirect_uri=https%3A%2F%2Fclient.org%2F
Authentication Response
El Authentication Response es el mensaje retornado por el Authorization Endpoint del OP en respuesta a un Authentication request enviado por el RP.
La respuesta incluye los parámetros "code" y "state", codificados con el formato "application/x-www-form-urlencoded" y añadidos a la *redirect_uri* especificada al enviar el Authentication request. La tabla a continuación presenta una breve descripción de los parámetros mencionados:
| Parámetro | Tipo | Descripción |
| code | Requerido | Código de autorización generado por el OP. Puede ser utilizado una única vez para obtener un ID Token y Access Token. Expira en 10 minutos. |
| state | Requerido si fue envíado | El valor exacto recibido del RP en el parámetro `state` del Authentication Request. |
Ejemplo de respuesta exitosa
HTTP/1.1 302 Found Location: https://client.org/? code=SplxlOBeZQQYbYS6WxSbIA &state=STRING_RANDOM
Si el request falla debido a que el parámetro *redirect_uri* es vacío, inválido o no coincide con ninguna de las URI de redirección configuradas al momento del registro o si el parámetro *client_id* es vacío o inválido, el OP mostrará al End-User una pantalla de error y no redireccionará el User-Agent a la URI inválida.
Por otra parte, si el End-User rechaza el request o si la autenticación falla por razones diferentes a las antes mencionadas, el OP informa al RP añadiendo a la URI especificada por el parámetro *redirect_uri*, los siguientes parámetros codificados con el formato "application/x-www-form-urlencoded":
| Parámetro | Tipo | Descripción |
|---|---|---|
| error | Requerido | Un código de error de los descritos en OpenID Connect 1.0 u OAuth 2.0 |
| error_description | Opcional | Descripción del error que provee información para ayudar a los desarrolladores a entender el error ocurrido. |
| state | Requerido si fue envíado | El valor exacto recibido del RP en el parámetro "state" del Authentication Request. |
Ejemplo de respuesta con error
HTTP/1.1 302 Found
Location: https://client.org/?
error=invalid_request
&error_description=
Unsupported%20response_type%20value
&state=STRING_RANDOM
Token Endpoint (/oidc/v1/token)
Para obtener un ID Token, un Access Token y opcionalmente un Refresh Token, el RP envía un Token Request al Token Endpoint del OP, quien responderá con un Token Response.
Token Request
Un RP realiza un Token Request presentando su código de autorización (`code`) ante el Token Endpoint del OP. Este request debe implementarse utilizando el método HTTP POST, y debe contener los siguientes parámetros serializados como Form Serialization:
| Parámetro | Tipo | Descripción |
|---|---|---|
| grant_type | Requerido | Tipo de credenciales a presentar. Debe ser "authorization_code". |
| code | Requerido | Código de autorización emitido por el OP, previamente tramitado en el Authentication Endpoint. |
| redirect_uri | Requerido | URI a donde debe ser redirigido el User Agent con la respuesta (Token Response). Debe ser una de las URIs configuradas al momento del registro del RP. |
Adicionalmente a estos parámetros, el _Token Request_ debe contener las credenciales de autenticación provistas al momento del registro (*client_id y client_secret*) siguiendo el esquema de autenticación HTTP Basic Auth.
Ejemplo de Token Request HTTP POST
Si `client_id = 123456789` y `client_secret = 0Pg8RabLluvuoG3`, un ejemplo de Token Request es:
POST /token HTTP/1.1 Host: https://auth-testing.iduruguay.gub.uy Content-Type: application/x-www-form-urlencoded Authorization: Basic MTIzNDU2Nzg5OjBQZzhSYWJMbHV2dW9HMw== grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA &redirect_uri=https%3A%2F%2Fclient.org%2F
En caso de que se quiera obtener un nuevo Access Token (Refresh), se puede utilizar el Token Endpoint enviando un Token Request que con los parámetros:
| Parámetro | Tipo | Descripción |
|---|---|---|
| grant_type | Requerido | Tipo de credenciales a presentar. Debe ser `refresh_token` |
| refresh_token | Requerido | `refresh_token` obtenido en el ID Token anterior. |
Token Response
Luego de recibido y validado un Token Request del RP, el OP procede a responder con un Token Response que incluye los siguientes parámetros codificados como `application/json`:
| Parámetro | Tipo | Descripción. |
|---|---|---|
| access_token | Requerido | Access Token emitido por el OP. |
| token_type | Requerido | Tipo de token. Será siempre "Bearer". |
| id_token | Requerido | ID Token asociado a la sesión de autenticación. |
| expires_in | Recomendado | Tiempo de vida del Access Token en segundos. Valor por defecto 60 minutos. |
| refresh_token | Opcional | Refresh Token que puede ser utilizado para obtener nuevos Access Tokens. |
Ejemplo de Token Response exitoso
HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store
Pragma: no-cache
{
"access_token": "bf6ab0e8fcef4ec7be5cfbfecb520c7f",
"token_type": "bearer",
"refresh_token": "6859d02ddb794e66b71321b587046344",
"expires_in": 3600,
"id_token": "eyJhbGciOiJSUzI1NiIsImtpZCI6IjFlOWdkazcifQ.ewogImlzc
yI6ICJodHRwOi8vc2VydmVyLmV4YW1wbGUuY29tIiwKICJzdWIiOiAiMjQ4Mjg5
NzYxMDAxIiwKICJhdWQiOiAiczZCaGRSa3F0MyIsCiAibm9uY2UiOiAibi0wUzZ
fV3pBMk1qIiwKICJleHAiOiAxMzExMjgxOTcwLAogImlhdCI6IDEzMTEyODA5Nz
AKfQ.ggW8hZ1EuVLuxNuuIJKX_V8a_OMXzR0EHR9R6jgdqrOOF4daGU96Sr_P6q
Jp6IcmD3HP99Obi1PRs-cwh3LO-p146waJ8IhehcwL7F09JdijmBqkvPeB2T9CJ
NqeGpe-gccMg4vfKjkM8FcGvnzZUN4_KSP0aAp1tOJ1zZwgjxqGByKHiOtX7Tpd
QyHE5lcMiKPXfEIQILVq0pc_E2DzL7emopWoaoZTF_m0_N0YzFC6g6EJbOEoRoS
K5hoDalrcvRYLSrQAZZKflyuVCyixEoV9GfNQC3_osjzw2PAithfubEEBLuVVk4
XUVrWOLrLl0nx7RkKU8NXNHq-rvKMzqg"
}
* NOTA: Para evitar que el User-Agent almacene en caché información sensible. El Token Response incluye los Headers HTTP "Cache-Control: no-store" y "Pragma: no-cache".
Si el Token Request es inválido o no pudo ser autorizado, el OP crea una respuesta con los siguientes parámetros codificados como "application/json" y un código de error "HTTP 400 Bad Request":
| Parámetro | Tipo | Descripción. |
| error | Requerido | Un código de error de los descritos en OAuth 2.0. |
| error_description | Opcional | Descripción del error que provee información para ayudar a los desarrolladores a entender el error ocurrido. |
Userinfo Endpoint (/oidc/v1/userinfo)
El UserInfo Endpoint es un endpoint protegido que retorna claims sobre el End-User autenticado. Para obtener estos claims, el RP envía un UserInfo Request acompañado por un Access Token obtenido a través del flujo de autenticación OpenID Connect. Los claims se retornan como clave-valor en la respuesta con formato JSON.
UserInfo Request
Un UserInfo Request puede ser implementado utilizando los métodos HTTP GET y HTTP POST, y en cualquier caso deberá incluir el header HTTP `Authorization` (definido por HTTP 1.1 siguiendo el esquema `Bearer` OAuth 2.0 Bearer Token Usage para incluir el Access Token previamente obtenido.
Ejemplo de UserInfo Request HTTP GET
Si `SlAV32hkKG` es el Access Token obtenido, un UserInfo Request podría ser:
GET /userinfo HTTP/1.1 Host: https://auth-testing.iduruguay.gub.uy Authorization: Bearer SlAV32hkKG
UserInfo Response
El UserInfo Response se retorna como respuesta a un UserInfo Request y devuelve los claims solicitados como atributos de un JSON. Por razones de privacidad, el OP puede elegir no retornar alguno de los claims solicitados (si, por ejemplo, no fue acordado al momento del registro).
El UserInfo Response siempre incluirá el campo "sub" (subject). Este, debe ser exactamente igual al campo `sub` del ID Token recibido. Si no coinciden, la respuesta debe considerarse inválida.
Ejemplo de UserInfo Response exitoso.
HTTP/1.1 200 OK
Content-Type: application/json
{
"sub": "248289761001",
"email": "juan@email.com",
"primer_nombre": "Juan",
"segundo_nombre": "José",
"primer_apellido": "Perez",
"segundo_apellido": "Martinez"
}
Si ocurre algún tipo de error, el UserInfo Endpoint retorna un Error Response tal y como lo especifica OAuth 2.0 Bearer Token Usage
Ejemplo de UserInfo Response con error.
HTTP/1.1 401 Unauthorized
WWW-Authenticate: error="invalid_token",
error_description="The Access Token expired"
JWKS Endpoint (/oidc/v1/jwks)
El estándar JSON Web Key (JWK) define una manera consistente de poder representar una clave criptográfica en formato JSON. JSON Web Key Set (JWKS) es, justamente, un set o conjunto de JWKs.
JWKS Endpoint expone las claves y algoritmos que el OP usa y puede ser útil a los RP para poder verificar la autenticidad de los tokens emitidos.
Este endpoint es parte del estándar Open ID Connect Discovery.
JWKS Request
En ID Uruguay, se puede acceder al JWKS Endpoint empleando el método HTTP GET
Ejemplo de JWKS Request HTTP GET
GET /oidc/v1/jwks HTTP/1.1 Host: https://auth-testing.iduruguay.gub.uy Content-Type: application/json
JWKS Response
El JWKS Response es una lista codificada en formato "application/json" con las JWKs que el servidor implementa.
Cada JWK tiene un identificador único ("kid"). Cada JWT contiene este identificador en el parámetro "header" para indicar que JWK usa.
La lista de parámetros completos son:
| Parámetro | Descripción |
|---|---|
| kty | Identifica la familia del algoritmo criptográfico utilizado. |
| alg | Identifica el algoritmo utilizado. ("RS256", "HS256"). |
| use | Identifica el uso previsto de la clave pública. Indica si se usa para cifrar datos ("enc") o para verificar la firma ("sig") |
| kid | Identificador único. |
| n | El módulo de la clave (2048 bit). Codificado en Base64. |
| e | El exponente de la clave (2048 bit). Codificado en Base64. |
Ejemplo de JWKS Response exitoso.
HTTP/1.1 200 OK
Content-Type: application/json
{
"keys": [
{
"kty": "RSA",
"alg": "RS256",
"use": "sig",
"kid": "84361b05da05b6f656f7e13e575f8431",
"n": "wYtA6llGGvE28lbJwXJ4Ks03IS9Y4tAJv_fyBollr7XTnNujGJ6N4easerObmD8iVI5TCQHCuh8z9HahtDVW_Ci8PHeokGgGcBDBLi0t4J9It_6mhVzWoGNN3HlzzJTVFIOnTykCzVkhEEoEPKL1SsDdv3NOffgLToC8YlJ2NS0",
"e": "AQAB"
}
]
}Logout Endpoint (/OIDC/V1/LOGOUT)
Cuando un proceso de cierre de sesión es iniciado en el SP, este podría querer solicitar que también se produzca en el OP.
Este endpoint forma parte del estandard OpenID Connect Session Management, el cual propone cierto mecanismo para llevar a cabo el cierre de sesión del ciudadano en el OP.
Este endpoint solo puede ser invocado mediante el método `HTTP GET`.
Adicionalmente, puede ser descubierto desde la sección OpenID Configuration Endpoint como "end_session_endpoint".
Los parámetros necesarios son:
| Parámetro | Tipo | Descripción. |
|---|---|---|
| id_token_hint | Requerido | Corresponde al "id_token" obtenido en el mecanismo de inicio de sesión del SP. Identifica al ciudadano y cliente en cuestión y valida la integridad del SP por el hecho de su posesión, ya que fue intercambiado de forma segura. |
| post_logout_redirect_uri | Opcional | URL a la cual será redireccionado el SP luego que el logout en el OP finalice exitosamente. Esta URL debe existir en la configuración que mantiene el OP del SP; si no existe o no es exactamente igual, será redireccionado al inicio del OP. |
| state | Opcional | Valor opaco para mantener el estado entre el pedido y la respuesta. Será retornado como parámetro en la "post_logout_redirect_uri" enviada. |
CASO RECOMENDADO OpenID Configuration Endpoint V2:
Documento JSON fue actualizado para corregir desviaciones del protocolo OpenID Connect detactadas en la versión anterior que se expone más abajo, disponible en la ruta formada por la concatención del Issuer (https://auth-testing.iduruguay.gub.uy/oidc/v2/.well-known/openid-config…) al string "/.well-known/openid-configuration".
https://auth-testing.iduruguay.gub.uy/oidc/v2/jwks
En este caso fue eliminado el campo x5c del jwks para solucionar un problema de compatibilidad con algunas soluciones, y se ajustó el wellknown para que coincidiera con el del token JWT en caso de presentar problemas con este campo “x5c” que se encuentra en el Endpoint V1 entonces se puede utilizar esta versión del Endpoint.
OpenID Configuration Endpoint Legacy
Hay un documento JSON disponible en la ruta formada por la concatención del Issuer (https: //auth-testing.iduruguay.gub.uy/oidc/v 1) al string "/.well-known/openid-configuration".
Este documento describe la configuración del proveedor OpenID ID Uruguay.
Este endpoint es parte del estándar OpenID Connect Discovery 1.0.
OpenID Provider Configuration Request
El documento de configuración debe ser consultado utilizando el método HTTP GET a la ruta especificada anteriormente.
OpenID Provider Configuration Response
La respuesta es un conjunto de Claims acerca de la configuración del proveedor OpenID ID Urguay, incluyendo todos los endpoint necesarios y la ubicación de la clave pública.
Claims que retornan varios valores, son representados como arreglos JSON.
Ejemplo de OpenID Provider Configuration Response exitoso.
HTTP/1.1 200 OK
Content-Type: application/json
{
"issuer": "https://auth-testing.iduruguay.gub.uy/oidc",
"authorization_endpoint": "https://auth-testing.iduruguay.gub.uy/oidc/authorize",
"token_endpoint": "https://auth-testing.iduruguay.gub.uy/oidc/token",
"userinfo_endpoint": "https://auth-testing.iduruguay.gub.uy/oidc/userinfo",
"end_session_endpoint" : "https://auth-testing.iduruguay.gub.uy/oidc/logout",
"id_token_signing_alg_values_supported": [
"HS256",
"RS256"
],
"jwks_uri": "https://auth-testing.iduruguay.gub.uy/oidc/jwks",
"scopes_supported": [
"openid",
"personal_info",
"profile",
"email",
"document",
"auth_info"
],
"response_types_supported": [
"code"
],
acr_values_supported: [
"urn:iduruguay:nid:0",
"urn:iduruguay:nid:1",
"urn:iduruguay:nid:2",
"urn:iduruguay:nid:3"
],
subject_types_supported: [
"public"
],
"claims_parameter_supported": true,
"claims_supported": [
"nombre_completo",
"primer_nombre",
"segundo_nombre",
"primer_apellido",
"segundo_apellido",
"uid",
"name",
"given_name",
"family_name",
"pais_documento",
"tipo_documento",
"numero_documento",
"email",
"email_verified",
"rid",
"nid",
"ae"
],
"service_documentation": "https://centroderecursos.agesic.gub.uy/"
}
Solicitud de cliente OpenID Connect TEST de ID Uruguay: acceder a la solicitud Integracion ID Uruguay OpenID Connect