Configuración de inicio de sesión de Entra ID

Power Portals Pro inicia sesión de usuarios con Microsoft a través del proveedor estándar AddMicrosoftAccount de ASP.NET Core, que requiere un registro de la app en el ID de Microsoft Entra. El registro es lo que indica a Entra que tu portal puede pedir inicios de sesión, a dónde puede enviar a los usuarios de vuelta y con qué credenciales se demostrará a sí mismo. Esta página recorre todas las propiedades de las que realmente depende el portal.

Esta no es la app de conexión Dataverse

Un portal típico implica dos registros separados, y confundirlos es un error común en la primera ejecución. La aplicación de conexión Dataverse es un principal de servicio que lee y escribe datos mientras el propio portal y sus credenciales van bajo D365:ClientId / D365:ClientSecret. El registro descrito en esta página es solo para iniciar sesión con usuarios, y sus credenciales van bajo Authentication:Microsoft:ClientId / ClientSecret. Usa dos registros: necesitan propiedades diferentes y tienen un radio de explosión muy distinto si se filtran.

1. Registrar la solicitud

Crea el registro en el centro de administración de Microsoft Entra. Necesitas al menos el rol de Desarrollador de Aplicaciones en el tenant.

  1. Inicia sesión en el centro de administración de Entra y, si perteneces a más de un inquilino, usa el icono de Configuración para cambiar al inquilino que debería ser el propietario del registro. Un registro de la app no puede moverse entre inquilinos después.
  2. Navega por Entra ID > Registros de la app y selecciona Nuevo registro.
  3. Introduce un Nombre, por Contoso Portal Sign-Inejemplo. Los usuarios ven este nombre en la pantalla de consentimiento, así que haz que sea algo que reconozcan como tu portal. Se puede cambiar más adelante.
  4. En Tipos de cuenta soportados, elige la audiencia que coincida con tu portal — consulta la tabla a continuación. Esta es la propiedad que decide quién puede iniciar sesión.
  5. Selecciona Registrarse.
  6. En la página de Resumen , copia el ID de la aplicación (cliente). Ese valor se convierte Authentication:Microsoft:ClientIden .

Selección de tipos de cuentas soportadas

Esta configuración es la puerta principal del portal. Elige la opción más estrecha que cubra a todos los que deben iniciar sesión:

Tipos de cuentas soportados ¿Quién puede iniciar sesión?
Solo inquilino individual — <tu inquilino> Solo usuarios e invitados en tu propio tenant. La elección correcta para un portal orientado a empleados — coincide con la audiencia de usuarios internos en la plantilla del proyecto.
Múltiples inquilinos de Entra ID Usuarios en cualquier tenant de Entra, pero no cuentas personales de Microsoft. Úsalo para portales de socios o B2B donde cada usuario inicia sesión con una cuenta de trabajo o colegio de su propia organización.
Cualquier Inquilino Entra ID + Cuentas personales de Microsoft Cuentas de trabajo, estudios y personales (Outlook.com, Hotmail, Xbox). La opción más amplia, y la opción habitual para un portal orientado al cliente donde los visitantes pueden no pertenecer a ninguna organización.
Solo cuentas personales Solo cuentas de Microsoft para consumidores — no cuentas de trabajo ni de estudios.

Nota

El proveedor ASP.NET Core de Microsoft siempre autoriza contra el endpoint multiaudiencia /common/ , por lo que la configuración de Tipos de cuenta soportada de registro — no tu código de aplicación — es lo que realmente acepta o rechaza una cuenta determinada. Si una cuenta es rechazada con AADSTS50020, el registro es más limitado que el público que pretendías.

2. Añadir el URI de Redirección

Tras un inicio de sesión exitoso, Entra envía al usuario de vuelta a tu portal en la ruta de devolución del proveedor, que es /signin-microsoft. Entra solo redirige a direcciones registradas de antemano, por lo que cada host en el que se ejecuta tu portal necesita su propia entrada.

  1. Abre Autenticación en Gestionar y luego selecciona Añadir plataforma.
  2. Elige la plataforma web — no la aplicación de página única. El servidor portal realiza el intercambio de tokens usando el secreto del cliente, y eso se mantiene para los hosts de Blazor WebAssembly y React, donde el inicio de sesión sigue gestionándose en el lado del servidor.
  3. Introduce la dirección de tu portal seguida de /signin-microsoft.
  4. Repite para cada entorno. La URL de desarrollo de launchSettings.json cada host desplegado y cada servidor necesita su propio URI de redirección. Pueden compartir un registro, o puedes mantener un registro separado por entorno.

Importante

El URI de redirección debe coincidir exactamente con lo que envía el portal — esquema, host, puerto y ruta. https://localhost:7228/signin-microsoft y https://localhost:7228/signin-microsoft/ no son la misma dirección, ni tampoco dos puertos diferentes. Entra requiere https para todo excepto localhost.

Si el portal se ejecuta detrás de un proxy inverso, balanceador de carga o entrada de contenedor que termina TLS, configura el middleware de cabeceras redirigidas de ASP.NET Core. Sin él, la app cree que la solicitud llegó por HTTP simple y construye un http:// URI de redirección, que no coincidirá con el registrado https:// .

3. Crear un secreto de cliente

El secreto es cómo tu portal demuestra que realmente es la aplicación registrada cuando intercambia el código de autorización por un token.

  1. Abre Certificados y secretos en Gestionar y selecciona la pestaña de secretos del cliente.
  2. Selecciona nuevo secreto del cliente, dale una descripción que nombre el entorno (por ejemplo portal-production), y elige un plazo de caducidad.
  3. Copia la columna Valor inmediatamente — no el ID Secreto. El valor se muestra solo una vez, y se convierte Authentication:Microsoft:ClientSecreten .

Importante

Los secretos del cliente expiran, y 24 meses es el máximo. Cuando uno expira, cada inicio de sesión de Microsoft falla AADSTS7000215 hasta que se reemplaza, así que sigue la fecha de caducidad y rota antes de ella. Para producción, las credenciales de certificado o una credencial de identidad federada evitan por completo el problema del secreto de expiración.

4. Verificar permisos de la API

Se concede automáticamente un nuevo registro en Microsoft Graph User.Read (delegado), y ese es el único permiso que necesita el flujo de inicio de sesión. El proveedor solicita el https://graph.microsoft.com/user.read alcance y lee el perfil del usuario iniciado sesión desde https://graph.microsoft.com/v1.0/me. Si alguien ha eliminado ese permiso, añádelo de nuevo bajo permisos de la API. Conceder el consentimiento del administrador es opcional en la mayoría de los tenants de la fuerza laboral, pero evita mostrar a cada usuario un aviso de consentimiento en el primer inicio de sesión; en los tenants externos es obligatorio.

Power Portals Pro lee lo siguiente de ese perfil cuando enlaza o crea un usuario del portal:

Propiedad del grafo Reclamación Cómo lo utiliza el portal
id NameIdentifier La clave estable para el inicio de sesión externo. Se almacena contra el usuario del portal para que la misma cuenta de Microsoft se resuelva al mismo usuario en cada inicio de sesión posterior.
mail / userPrincipalName Email Se compara con contactos existentes (y usuarios del sistema) para encontrar al usuario del portal al que pertenece este inicio de sesión, y se usa como dirección de correo electrónico cuando se crea una nueva cuenta. Es configurable en qué columnas de contactos se buscan — véase Emparejamiento de un inicio de sesión externo con un contacto.
givenName, surname GivenName, Surname Pre-rellena el nombre y apellido en el formulario de registro cuando se crea un nuevo usuario del portal.

Nota

La mail propiedad está vacía para cuentas que no tienen buzón de Exchange, en cuyo caso el proveedor vuelve a userPrincipalName. Un UPN no siempre es una dirección de correo electrónico enrutable — las cuentas de invitados en particular llevan UPN con forma similar user_contoso.com#EXT#@yourtenant.onmicrosoft.com — así que si tu portal empareja a los usuarios por correo electrónico, espera que esas cuentas no coincidan con un contacto existente.

5. Guardar el ID del cliente y el secreto

El portal lee ambos valores de configuración en la Authentication:Microsoft sección. En desarrollo, mantenlos en secretos de usuario en lugar de appsettings.json hacerlo para que nunca lleguen al control de versiones:

O desde la línea de comandos, en el directorio del proyecto del servidor:

Propina

En entornos alojados, suministran las mismas claves que las variables de entorno o desde un almacén secreto. Las variables de entorno usan un doble guion bajo en lugar de los dos puntos — Authentication__Microsoft__ClientId y Authentication__Microsoft__ClientSecret — porque el separador de dos puntos no es portátil entre plataformas.

6. Habilitar al proveedor en Program.cs

Registra el proveedor junto con el resto de tu configuración de autenticación en los proyectos Program.csdel servidor:

La plantilla del proyecto escribe esta llamada para ti cuando seleccionas la audiencia de Usuarios internos o Ambos , o cuando optas por iniciar sesión con Microsoft para usuarios externos. Si generaste el proyecto sin ella, la misma llamada se envía comentada en Program.cs — quita el comentario y proporciona los dos valores de configuración.

7. Iniciar sesión y verificar

Ejecuta el portal y abre la página de inicio de sesión. Ahora aparece un botón de Microsoft entre las opciones de inicio de sesión. La primera vez que una cuenta inicia sesión, el portal vincula la identidad de Microsoft con un usuario del portal — emparejando a un contacto existente por correo electrónico cuando pueda, y de lo contrario guiando al visitante durante el registro con el nombre y el correo electrónico de su perfil ya rellenados.

Si la cuenta también existe como Dataverse systemuser, la sesión puede ejecutarse como ese usuario interno en lugar de como contacto. Ese comportamiento no necesita configuración adicional en el registro de la app: Ver Inicio de sesión de SystemUser

Resolución de problemas