Wiki

ID Uruguay - Integración con OpenID Connect

Introducción

¿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 autenticandose en otro sitio (OpenID Provider) que ya contiene sus datos.

Login with buttons

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 click. 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 los sitios que utilizan cada día. 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 que 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.

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 como es posible operar como un cliente del mismo para obtener información verificada de los ciudadanos, 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.

Roles

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.

Flujo Abstracto

> 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 permitir a estos últimos 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, email y género entre otros. Y los agrupa en scopes, que permiten a un RP definir que 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 primer_nombre, segundo_nombre, primer_apellido, segundo_apellido, rid Nombres y apellidos del usuario, 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.
document pais_documento, tipo_documento, numero_documento Información sobre el documento del usuario
email email, email_verified Correo electrónico y si el mismo está verificado.

De este modo, un RP podrá obtener los datos incluídos en los scopes que solicite, previa autorización del End-User (propietario de dichos datos).

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 son datos técnicos.
Una vez entregado el formulario testing, se te proveerá de un ID y un Secret para que puedan autenticarse 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 la autenticación y autorización del mismo. 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

Esquema Autorization Code Flow

> 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. La misma 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.`

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.

Pantalla de error

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"
    }
  ]
}

OpenID Configuration Endpoint

Hay un documento JSON disponible en la ruta formada por la concatención del Issuer (https://auth-testing.iduruguay.gub.uy/oidc/v1) 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",
  "id_token_signing_alg_values_supported": [
    "HS256",
    "RS256"
  ],
  "jwks_uri": "https://auth-testing.iduruguay.gub.uy/oidc/jwks",
  "scopes_supported": [
    "openid",
    "personal_info",
    "email",
    "document"
  ],
  "response_types_supported": [
    "code"
  ],
  "claims_parameter_supported": false,
  "service_documentation": "https://centroderecursos.agesic.gub.uy/"
}

Referencias

- OpenID Connect 1.0

- OpenID Connect Discovery 1.0

- OAuth 2.0

- JSON Web Token (JWT)

- JSON Web Key (JWK)

- JWT

2636 Accesos
Promedio (0 Votos)