Compartir vía


Aplicación de escritorio que llama a las API web: Registro de aplicación

En este artículo se tratan los detalles del registro de una aplicación de escritorio.

Tipos de cuenta admitidos

Los tipos de cuenta que se admiten en una aplicación de escritorio dependen de la experiencia que quiera destacar. Debido a esta relación, los tipos de cuenta admitidos dependen de los flujos que desee usar.

Público para la adquisición interactiva de tokens

Si la aplicación de escritorio usa la autenticación interactiva, puede iniciar la sesión de los usuarios desde cualquier tipo de cuenta.

Audiencia para flujos silenciosos de la aplicación de escritorio

  • Para usar la autenticación integrada de Windows o un nombre de usuario y una contraseña, la aplicación debe iniciar la sesión de los usuarios en su propio inquilino, por ejemplo, si es un desarrollador de línea de negocio (LOB). O bien, en organizaciones de Microsoft Entra, la aplicación debe iniciar la sesión de los usuarios en su propio inquilino si se trata de un escenario de ISV. Estos flujos de autenticación no son compatibles con las cuentas personales de Microsoft.
  • Si inicia la sesión de los usuarios con identidades sociales que pasan una autoridad y directiva de negocio a comercio (B2C), solo puede usar la autenticación interactiva y de nombre de usuario y contraseña.

URI de redirección

Los URI de redirección que se utilizan en una aplicación de escritorio dependen del flujo que se quiera utilizar.

Especifique el URI de redirección para su aplicación configurando los ajustes de la plataforma para la aplicación en Registros de aplicaciones en el centro de administración de Microsoft Entra.

  • En el caso de las aplicaciones que usen Web Authentication Manager (WAM), no es preciso configurar los identificadores URI de redireccionamiento en MSAL, pero deben configurarse en el registro de la aplicación.

  • Para las aplicaciones que usan la autenticación interactiva:

    • Aplicaciones que usan exploradores incrustados: https://login.microsoftonline.com/common/oauth2/nativeclient (Nota: Si la aplicación abriría una ventana que normalmente no contiene ninguna barra de direcciones, se está usando el "explorador incrustado").
    • Aplicaciones que usan exploradores del sistema: http://localhost (Nota: Si la aplicación abriría el explorador predeterminado del sistema (como Edge, Chrome, Firefox, etc.) para visitar el portal de inicio de sesión de Microsoft, se está usando el "explorador del sistema").

    Importante

    Como procedimiento recomendado de seguridad, se aconseja establecer explícitamente https://login.microsoftonline.com/common/oauth2/nativeclient o http://localhost como URI de redirección. Algunas bibliotecas de autenticación como MSAL.NET usan un valor predeterminado de urn:ietf:wg:oauth:2.0:oob cuando no se especifica ningún otro URI de redirección, lo que no se recomienda. Este valor predeterminado se actualizará como un cambio importante en la próxima versión principal.

  • Si compila una aplicación nativa de Objective-C o Swift para macOS, registre el URI de redirección en función del identificador de agrupación de la aplicación, con el formato siguiente: msauth.<your.app.bundle.id>://auth. Reemplace <your.app.bundle.id> por el identificador de paquete de la aplicación.

  • Si compila una aplicación Electron de Node.js, use un protocolo de cadena personalizado en lugar de un URI de redirección web normal (https://) para controlar el paso de redireccionamiento del flujo de autorización, por ejemplo msal{Your_Application/Client_Id}://auth (como msal00001111-aaaa-2222-bbbb-3333cccc4444://auth). El nombre del protocolo de cadena personalizado no debe ser obvio de adivinar y debe seguir las sugerencias de la especificación de OAuth 2.0 para aplicaciones nativas.

  • Si la aplicación solo utiliza la autenticación integrada de Windows o un nombre de usuario y una contraseña, no es necesario que registre ningún URI de redirección para la aplicación. Estos flujos realizan un recorrido de ida y vuelta al punto de conexión de la plataforma de identidad de Microsoft v2.0. No se volverá a llamar a la aplicación en ningún URI específico.

  • Para distinguir el flujo de código de dispositivo, la autenticación integrada de Windows y el nombre de usuario y la contraseña de una aplicación cliente confidencial mediante un flujo de credenciales de cliente usado en aplicaciones de demonio, ninguna de las cuales requiere un URI de redirección, configúrela como aplicación cliente pública. Para lograr esta configuración:

    1. En el Centro de administración de Microsoft Entra, seleccione la aplicación en Registros de aplicaciones y a continuación, seleccione Autenticación.

    2. En Configuración avanzada>Permitir flujos de cliente público>Habilitar los flujos móviles y de escritorio siguientes: , seleccione .

      Habilite la opción de cliente público en el panel Autenticación de Azure Portal

Permisos de API

Las aplicaciones de escritorio llaman a las API en nombre del usuario que tiene la sesión iniciada. Tienen que solicitar permisos delegados. No pueden solicitar permisos de la aplicación, que solo se controlan en las aplicaciones de demonio.

Pasos siguientes

Avance al siguiente artículo de este escenario, Configuración del código de la aplicación.