Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
Importante
A partir del 1 de mayo de 2025, Azure AD B2C ya no estará disponible para la compra por parte de nuevos clientes. Obtenga más información en nuestras preguntas más frecuentes.
En este artículo se describe cómo administrar el acceso de usuario a las aplicaciones mediante Azure Active Directory B2C (Azure AD B2C). La administración de acceso en la aplicación incluye:
- Identificación de menores y control del acceso del usuario a la aplicación.
- Requerir consentimiento parental para que los menores usen sus aplicaciones.
- Recopilación de datos de nacimiento y país o región de los usuarios.
- Capturar un acuerdo de términos de uso y restringir el acceso.
Nota:
En Azure Active Directory B2C, las directivas personalizadas se han diseñado principalmente para abordar escenarios complejos. Para la mayoría de los escenarios, se recomienda usar flujos de usuario integrados. Si no lo ha hecho, obtenga información sobre el paquete de inicio de directivas personalizadas en Introducción a las directivas personalizadas en Active Directory B2C.
Control del acceso secundario
Las aplicaciones y organizaciones pueden decidir impedir que los menores usen aplicaciones y servicios que no están destinados a esta audiencia. Como alternativa, las aplicaciones y las organizaciones pueden decidir aceptar a menores y, posteriormente, administrar el consentimiento parental, y ofrecer experiencias permitidas para menores según lo dictado por las reglas de negocios y permitidos por la regulación.
Si un usuario se identifica como un menor, puede establecer el flujo de usuario en Azure AD B2C en una de las tres opciones:
Devuelva un id_token JWT firmado a la aplicación: El usuario está registrado en el directorio y se devuelve un token a la aplicación. A continuación, la aplicación continúa aplicando reglas de negocios. Por ejemplo, la aplicación puede continuar con un proceso de consentimiento parental. Para usar este método, elija recibir los atributos ageGroup y consentProvidedForMinor de la aplicación.
Enviar un token JSON sin firmar a la aplicación: Azure AD B2C notifica a la aplicación que el usuario es un menor y proporciona el estado del consentimiento parental del usuario. A continuación, la aplicación continúa aplicando reglas de negocios. Un token JSON no completa una autenticación correcta con la aplicación. La aplicación debe procesar al usuario no autenticado según las afirmaciones incluidas en el token JSON, que pueden incluir el nombre, el correo electrónico, ageGroup y consentProvidedForMinor.
Bloquear al usuario: si un usuario es un menor y no se ha proporcionado el consentimiento parental, Azure AD B2C puede notificar al usuario que están bloqueados. No se emite ningún token, se bloquea el acceso y la cuenta de usuario no se crea durante un recorrido de registro. Para implementar esta notificación, proporcione una página de contenido HTML/CSS adecuada para informar al usuario y presentar las opciones adecuadas. La aplicación no necesita ninguna otra acción para los nuevos registros.
Obtener consentimiento parental
En función de la regulación de la aplicación, es posible que un usuario que haya comprobado como adulto deba conceder el consentimiento parental. Azure AD B2C no proporciona una experiencia para comprobar la edad de un individuo y, a continuación, permitir que un adulto comprobado conceda consentimiento parental a un menor. La aplicación u otro proveedor de servicios debe proporcionar esta experiencia.
A continuación se muestra un ejemplo de un flujo de usuario para recopilar el consentimiento parental:
Una operación de Microsoft Graph API identifica al usuario como un menor y devuelve los datos de usuario a la aplicación en forma de token JSON sin firmar.
La aplicación procesa el token JSON y muestra una pantalla al menor, notificándoles que se requiere el consentimiento parental y solicitando el consentimiento de un padre en línea.
Azure AD B2C muestra un recorrido de inicio de sesión en el que el usuario puede iniciar sesión normalmente y emite un token a la aplicación que está establecida para incluir legalAgeGroupClassification = "minorWithParentalConsent". La aplicación recopila la dirección de correo electrónico del padre y verifica que el padre es un adulto. Para ello, usa una fuente de confianza, como una oficina de identificación nacional o regional, comprobación de licencias o prueba de tarjeta de crédito. Si la comprobación se realiza correctamente, la aplicación solicita al menor que inicie sesión mediante el flujo de usuario de Azure AD B2C. Si se deniega el consentimiento (por ejemplo, si legalAgeGroupClassification = "minorWithoutParentalConsent"), Azure AD B2C devuelve un token JSON (no un inicio de sesión) a la aplicación para reiniciar el proceso de consentimiento. Opcionalmente, es posible personalizar el flujo de usuario para que un menor o un adulto puedan recuperar el acceso a la cuenta de un menor enviando un código de registro a la dirección de correo electrónico del menor o la dirección de correo electrónico del adulto en el registro.
La aplicación ofrece una opción al menor para revocar el consentimiento.
Cuando el menor o el adulto revoca el consentimiento, microsoft Graph API se puede usar para cambiar consentProvidedForMinor a denegado. Como alternativa, la aplicación puede optar por eliminar un menor cuyo consentimiento se haya revocado. Es posible personalizar el flujo de usuario opcionalmente para que el menor autenticado (o el padre o la madre que esté usando la cuenta del menor) pueda revocar el consentimiento. Azure AD B2C registra consentProvidedForMinor como denegado.
Para obtener más información sobre legalAgeGroupClassification, consentProvidedForMinor y ageGroup, consulte Tipo de recurso de usuario. Para obtener más información sobre los atributos personalizados, consulte Uso de atributos personalizados para recopilar información sobre los consumidores. Al abordar los atributos extendidos mediante Microsoft Graph API, debe usar la versión larga del atributo, como extension_18b70cf9bb834edd8f38521c2583cd86_dateOfBirth: 2011-01-01T00:00:00Z.
Recopilación de datos de fecha de nacimiento y país o región
Las aplicaciones pueden confiar en Azure AD B2C para recopilar la fecha de nacimiento (DOB) y la información de país o región de todos los usuarios durante el registro. Si esta información aún no existe, la aplicación puede solicitarla al usuario durante el siguiente recorrido de autenticación (inicio de sesión). Los usuarios no pueden continuar sin proporcionar su información de DOB y país o región. Azure AD B2C usa la información para determinar si el individuo se considera un menor según los estándares normativos de ese país o región.
Un flujo de usuario personalizado puede recopilar información de fecha de nacimiento y país o región, y usar la transformación de reclamaciones de Azure AD B2C para determinar el ageGroup y conservar el resultado (o conservar directamente la información de fecha de nacimiento y país o región) en el directorio.
Los pasos siguientes muestran la lógica que se usa para calcular ageGroup a partir de la fecha de nacimiento del usuario:
Intente encontrar el país o región por el código de país o región en la lista. Si no se encuentra el país o región, vuelva a Predeterminado.
Si el nodo MinorConsent está presente en el elemento country/region:
a) Calcule la fecha en la que el usuario debe haber nacido para considerarse adulto. Por ejemplo, si la fecha actual es el 14 de marzo de 2015 y MinorConsent es 18, la fecha de nacimiento no debe ser posterior al 14 de marzo de 2000.
b. Compare la fecha de nacimiento mínima con la fecha de nacimiento real. Si la fecha mínima de nacimiento es anterior a la fecha de nacimiento del usuario, el cálculo devuelve Minor como cálculo del grupo de edad.
Si el nodo MinorNoConsentRequired está presente en el elemento country/region, repita los pasos 2a y 2b con el valor de MinorNoConsentRequired. La salida de 2b devuelve MinorNoConsentRequired si la fecha de nacimiento mínima es anterior a la fecha de nacimiento del usuario.
Si ninguno de los cálculos devuelve true, el cálculo devuelve Adult.
Si una aplicación ha recopilado datos doB o país o región de forma confiable por otros métodos, la aplicación puede usar Graph API para actualizar el registro de usuario con esta información. Por ejemplo:
- Si se sabe que un usuario es un adulto, actualice el atributo de directorio ageGroup con un valor de Adult.
- Si se sabe que un usuario es menor, actualice el atributo de directorio ageGroup con un valor de Minor y establezca consentProvidedForMinor, según corresponda.
Reglas de cálculo secundarias
Las restricciones por edad implican dos valores de edad: la edad en que alguien deja de ser considerado menor, y la edad a la que un menor debe tener el consentimiento de los padres. En la tabla siguiente se enumeran las reglas de edad que se usan para definir un menor y un menor que requiere consentimiento.
| País/región | Nombre del país o región | Edad de consentimiento menor | Edad menor |
|---|---|---|---|
| Predeterminado | Ninguno | Ninguno | 18 |
| Æ | Emiratos Árabes Unidos | Ninguno | Veintiuno |
| EN | Austria | 14 | 18 |
| SER | Bélgica | 14 | 18 |
| BG | Bulgaria | 16 | 18 |
| BH | Bahréin | Ninguno | Veintiuno |
| CM | Camerún | Ninguno | Veintiuno |
| CY | Chipre | 16 | 18 |
| CZ | República Checa | 16 | 18 |
| DE | Alemania | 16 | 18 |
| DK | Dinamarca | 16 | 18 |
| EE | Estonia | 16 | 18 |
| EG | Egipto | Ninguno | Veintiuno |
| ES | España | 13 | 18 |
| FR | Francia | 16 | 18 |
| GB | Reino Unido | 13 | 18 |
| GR | Grecia | 16 | 18 |
| Recursos Humanos | Croacia | 16 | 18 |
| HU | Hungría | 16 | 18 |
| Internet Explorer | Irlanda | 13 | 18 |
| TI | Italia | 16 | 18 |
| KR | Corea, República de | 14 | 18 |
| LT | Lituania | 16 | 18 |
| LU | Luxemburgo | 16 | 18 |
| LV | Letonia | 16 | 18 |
| MT | Malta | 16 | 18 |
| N/D | Namibia | Ninguno | Veintiuno |
| NL | Países Bajos | 16 | 18 |
| PL | Polonia | 13 | 18 |
| PT | Portugal | 16 | 18 |
| RO | Rumania | 16 | 18 |
| SE | Suecia | 13 | 18 |
| SG | Singapur | Ninguno | Veintiuno |
| Sí | Eslovenia | 16 | 18 |
| SK | Eslovaquia | 16 | 18 |
| TD | Chad | Ninguno | Veintiuno |
| ÉSIMO | Tailandia | Ninguno | 20 |
| TW | Taiwán | Ninguno | 20 |
| EE. UU. | Estados Unidos | 13 | 18 |
Capturar acuerdo de términos de uso
Cuando desarrollas tu aplicación, normalmente registras la aceptación por parte de los usuarios de los términos de uso dentro de sus aplicaciones sin participación del directorio de usuarios, o con una participación mínima. Sin embargo, es posible usar un flujo de usuario de Azure AD B2C para recopilar la aceptación de los términos de uso de un usuario, restringir el acceso si no se concede la aceptación y aplicar la aceptación de cambios futuros en los términos de uso, según la fecha de la última aceptación y la fecha de la última versión de los términos de uso.
Los términos de uso también pueden incluir "Consentimiento para compartir datos con terceros". Dependiendo de las regulaciones locales y las reglas de negocios, puede recopilar la aceptación de un usuario de ambas condiciones combinadas, o puede permitir que el usuario acepte una condición y no la otra.
En los pasos siguientes se describe cómo administrar los términos de uso:
Registre la aceptación de los términos de uso y la fecha de aceptación mediante Graph API y atributos extendidos. Puede hacerlo mediante flujos de usuario integrados y directivas personalizadas. Se recomienda crear y usar los atributos extension_termsOfUseConsentDateTime y extension_termsOfUseConsentVersion .
Cree una casilla obligatoria con la etiqueta "Aceptar términos de uso" y registre el resultado durante el registro. Puede hacerlo mediante flujos de usuario integrados y directivas personalizadas.
Azure AD B2C almacena los términos de uso y la aceptación del usuario. Puede usar Graph API para consultar el estado de cualquier usuario; para ello, lea el atributo de extensión que se usa para registrar la respuesta (por ejemplo, lea termsOfUseTestUpdateDateTime). Puede hacerlo mediante flujos de usuario integrados y directivas personalizadas.
Requerir la aceptación de los términos de uso actualizados comparando la fecha de aceptación a la fecha de la versión más reciente de los términos de uso. Solo puede comparar las fechas mediante un flujo de usuario personalizado. Use el atributo extendido extension_termsOfUseConsentDateTime y compare el valor con la notificación de termsOfUseTextUpdateDateTime. Si la aceptación es antigua, cree una nueva aceptación. Para ello, muestre una pantalla autoafirmada. De lo contrario, bloquee el acceso mediante la lógica de directiva.
Requerir la aceptación de los términos de uso actualizados comparando el número de versión de la aceptación con el número de versión aceptado más reciente. Solo puede comparar números de versión mediante un flujo de usuario personalizado. Use el atributo extendido extension_termsOfUseConsentDateTime y compare el valor con la notificación de extension_termsOfUseConsentVersion. Si la aceptación es antigua, cree una nueva aceptación. Para ello, muestre una pantalla autoafirmada. De lo contrario, bloquee el acceso mediante la lógica de directiva.
Puede capturar la aceptación de los términos de uso en los escenarios siguientes:
- Un nuevo usuario se está registrando. Se muestran los términos de uso y se almacena el resultado de la aceptación.
- Un usuario inicia sesión que ha aceptado previamente los términos de uso más recientes o activos. No se muestran los términos de uso.
- Un usuario inicia sesión que aún no ha aceptado los términos de uso más recientes o activos. Se muestran los términos de uso y se almacena el resultado de la aceptación.
- Un usuario inicia sesión que ya ha aceptado una versión anterior de los términos de uso, que ahora se actualizan a la versión más reciente. Se muestran los términos de uso y se almacena el resultado de la aceptación.
En la imagen siguiente se muestra el flujo de usuario recomendado:
El siguiente es un ejemplo de consentimiento de términos de uso basado en la fecha de una notificación. Si la extension_termsOfUseConsentDateTime notificación es anterior a 2025-01-15T00:00:00, fuerza una nueva aceptación comprobando la termsOfUseConsentRequired notificación booleana y mostrando una pantalla autoafirmada.
<ClaimsTransformations>
<ClaimsTransformation Id="GetNewUserAgreeToTermsOfUseConsentDateTime" TransformationMethod="GetCurrentDateTime">
<OutputClaims>
<OutputClaim ClaimTypeReferenceId="extension_termsOfUseConsentDateTime" TransformationClaimType="currentDateTime" />
</OutputClaims>
</ClaimsTransformation>
<ClaimsTransformation Id="IsTermsOfUseConsentRequired" TransformationMethod="IsTermsOfUseConsentRequired">
<InputClaims>
<InputClaim ClaimTypeReferenceId="extension_termsOfUseConsentDateTime" TransformationClaimType="termsOfUseConsentDateTime" />
</InputClaims>
<InputParameters>
<InputParameter Id="termsOfUseTextUpdateDateTime" DataType="dateTime" Value="2025-01-15T00:00:00" />
</InputParameters>
<OutputClaims>
<OutputClaim ClaimTypeReferenceId="termsOfUseConsentRequired" TransformationClaimType="result" />
</OutputClaims>
</ClaimsTransformation>
</ClaimsTransformations>
A continuación se muestra un ejemplo de un consentimiento de términos de uso por versión en una reclamación. Si la extension_termsOfUseConsentVersion reclamación no es igual a V1, forzar una nueva aceptación comprobando la termsOfUseConsentRequired reclamación booleana y mostrando una pantalla autoafirmada.
<ClaimsTransformations>
<ClaimsTransformation Id="GetEmptyTermsOfUseConsentVersionForNewUser" TransformationMethod="CreateStringClaim">
<InputParameters>
<InputParameter Id="value" DataType="string" Value=""/>
</InputParameters>
<OutputClaims>
<OutputClaim ClaimTypeReferenceId="extension_termsOfUseConsentVersion" TransformationClaimType="createdClaim" />
</OutputClaims>
</ClaimsTransformation>
<ClaimsTransformation Id="GetNewUserAgreeToTermsOfUseConsentVersion" TransformationMethod="CreateStringClaim">
<InputParameters>
<InputParameter Id="value" DataType="string" Value="V1"/>
</InputParameters>
<OutputClaims>
<OutputClaim ClaimTypeReferenceId="extension_termsOfUseConsentVersion" TransformationClaimType="createdClaim" />
</OutputClaims>
</ClaimsTransformation>
<ClaimsTransformation Id="IsTermsOfUseConsentRequiredForVersion" TransformationMethod="CompareClaimToValue">
<InputClaims>
<InputClaim ClaimTypeReferenceId="extension_termsOfUseConsentVersion" TransformationClaimType="inputClaim1" />
</InputClaims>
<InputParameters>
<InputParameter Id="compareTo" DataType="string" Value="V1" />
<InputParameter Id="operator" DataType="string" Value="not equal" />
<InputParameter Id="ignoreCase" DataType="string" Value="true" />
</InputParameters>
<OutputClaims>
<OutputClaim ClaimTypeReferenceId="termsOfUseConsentRequired" TransformationClaimType="outputClaim" />
</OutputClaims>
</ClaimsTransformation>
</ClaimsTransformations>
Pasos siguientes
- Habilitación del acceso según la edad en Azure AD B2C.
- Para obtener información sobre cómo eliminar y exportar datos de usuario, consulte Administración de datos de usuario.
- Para ver un ejemplo de directiva personalizada que implementa un mensaje de condiciones de uso, consulte Una directiva personalizada de B2C IEF: registro e inicio de sesión con el aviso "Condiciones de uso".