REGISTRO DE MECANISMO DE AUTENTICACIÓN
Para probar el mecanismo de autenticación, debe seleccionar el mecanismo de “autenticación”.

A continuación, deberá seleccionar el tipo de aplicación:
- Aplicación web: Las aplicaciones web pueden ser servidores de aplicaciones que interactúan directamente con el usuario a través de un navegador web. Por lo general, este tipo de aplicación utiliza el flujo de autorización authorization_code para obtener tokens de acceso.
- Aplicación móvil: Este valor indica que la aplicación cliente es una aplicación nativa, es decir, una aplicación instalada en un dispositivo cliente, como un dispositivo móvil o una aplicación de escritorio. Las aplicaciones nativas pueden tener restricciones de seguridad diferentes y pueden requerir flujos de autorización específicos, como el flujo implícito. (En nuestro caso token_endpoint_auth_method: ninguno).

Se habilitará un formulario que se encuentra dividido en 3 pasos:
-
Enlaces de redirección. Registra los enlaces de redirección que permiten que los usuarios accedan a la aplicación.
a. URI de redirección al iniciar sesión (obligatorio): Ingresa la URL a la que los usuarios serán redireccionados después de iniciar sesión.
b. URI de redirección al cerrar sesión (obligatorio): Ingresa la URL a la que los usuarios serán redireccionados después de cerrar sesión.
c. URI de política de privacidad (opcional): Proporciona la URL donde se encuentran las políticas de privacidad de la aplicación; esta se mostrará la primera vez que el usuario quiera ingresar a tu sistema.

-
Configuración de autorización. Seleccione la forma en la que desea solicitar un token de acceso.
a. Tipo de concesión de credenciales (obligatorio). Selecciona el tipo de concesión que se usará para obtener el token de acceso:-
Authorization Code (obligatorio): Este tipo de concesión se utiliza en el flujo de autorización estándar (Authorization Code Flow). El cliente obtiene un código de autorización después de que el usuario se autentica en el proveedor de identidad. Luego, el cliente intercambia ese código de autorización por un token de acceso.
-
Refresh Token (opcional): El refresh token sirve para acceder a los recursos protegidos sin que el usuario esté presente o sin que el usuario tenga que autenticarse nuevamente.
-
Client credentials (opcional): Flujo donde se obtiene un token de acceso usando únicamente las credenciales del cliente, se emplea en escenarios backend-to-backend ya que el token representa la identidad de la aplicación.
-
None (aplicación móvil): En el caso de ser una aplicación móvil, el sistema no le permitirá elegir ninguna de las opciones anteriores y se marcará automáticamente la opción “none”.
b. Endpoint de autorización de token (obligatorio). Selecciona el método de autenticación que se utilizará en el endpoint de token.
- Basic: Debes seleccionar esta opción si tu sistema cliente envía su identificador client_id y su secreto compartido client_secret en el encabezado de autorización usando el esquema "Basic".
- Post: Debes seleccionar esta opción si tu sistema cliente envía su identificador y su secreto como parámetros en el cuerpo de la solicitud HTTP.
c. Habilitar la opción de registrar dispositivos de confianza (opcional). Marca esta opción para permitir que los usuarios salten el segundo factor de autenticación en dispositivos de confianza.
-

-
Solicitud de scopes. Seleccionar la información personal que solicitara el sistema cliente al ciudadano. Los scopes pueden ser requeridos, opcionales y no requeridos.
a. Scopes "Requerido". Recurso en el cual el ciudadano debe dar su consentimiento para poder ingresar al sistema.
b. Scopes “Opcionales”. Recurso que el ciudadano puede o no dar su consentimiento, de todos modos ingresará al sistema.
c. Scopes “No requeridos”. Recurso que no será entregado al sistema cliente una vez el usuario se haya logueado al sistema.
Los scopes que pueden seleccionar son los siguientes:

| Nombre | Descripción | Tipo |
|---|---|---|
| Nombre completo y documento de identidad | Permiso para acceder al número de documento de identidad y nombre completo del usuario, este se denomina profile. | Requerido |
| Fecha de nacimiento | Permiso para acceder a la fecha de nacimiento del usuario. Pedirlo sólo si se hará uso de ella dentro del sistema cliente. | |
| Correo Electrónico | Permiso para acceder a la dirección de correo electrónico del usuario. Pedirlo sólo si se hará uso de él dentro del sistema cliente. | |
| Número de teléfono celular | Permiso para acceder al número de celular del usuario. Pedirlo sólo si se hará uso de él dentro del sistema cliente. | |
| openid | Permiso para acceder a la información de la autenticación del usuario | requerido |
| offline_access | Permiso para acceder a refresh token | requerido |
Después de llenar todos los parámetros requeridos, el sistema desplegará todos los datos necesarios para que puedan probar el mecanismo. Asimismo, podrá descargar usuarios de prueba para que pueda probar el mecanismo.

En el apartado “Datos de la configuración” encontrará los parámetros necesarios para consumir este mecanismo a través de clientes del protocolo OAuth 2.0 como ser “OpenIdClient”.