Gerenciar o acesso do usuário no Azure Active Directory B2C

Este artigo discute como gerenciar o acesso do usuário aos seus aplicativos usando o Azure AD B2C (Azure Active Directory B2C). O gerenciamento de acesso em seu aplicativo inclui:

• Identificar menores e controlar o acesso do usuário ao seu aplicativo.
• Exigir consentimento dos pais para que os menores usem seus aplicativos.
• Coletando dados de nascimento e país/região de usuários.
• Capturar um contrato de termos de uso e restrição de acesso.

Controlar o acesso de menores

Aplicativos e organizações podem decidir impedir que menores usem aplicativos e serviços que não são direcionados a esse público. Como alternativa, aplicativos e organizações podem decidir aceitar menores e, posteriormente, gerenciar o consentimento dos pais e fornecer experiências permitidas para menores, conforme ditado pelas regras de negócios e permitido pela regulamentação.

Se um usuário for identificado como um menor, você poderá definir o fluxo de usuário no Azure AD B2C como uma das três opções:

• Envie um id_token JWT assinado de volta para o aplicativo: O usuário está registrado no diretório, e um token é retornado para o aplicativo. Em seguida, o aplicativo continua aplicando regras de negócios. Por exemplo, o aplicativo pode continuar com um processo de consentimento dos pais. Para usar este método, escolha receber as declarações ageGroup e consentProvidedForMinor do aplicativo.

• Enviar um token JSON não assinado para o aplicativo: o Azure AD B2C notifica o aplicativo que o usuário é menor de idade e fornece o status do consentimento dos pais do usuário. Em seguida, o aplicativo continua aplicando regras de negócios. Um token JSON não conclui uma autenticação bem-sucedida com o aplicativo. O aplicativo deve processar o usuário não autenticado de acordo com as declarações incluídas no token JSON, que podem incluir nome, email, ageGroup e consentProvidedForMinor.

• Bloqueie o usuário: se um usuário for menor e o consentimento dos pais não tiver sido fornecido, o Azure AD B2C poderá notificar o usuário de que ele está bloqueado. Nenhum token é emitido, o acesso é bloqueado e a conta de usuário não é criada durante um percurso de registro. Para implementar essa notificação, você fornece uma página de conteúdo HTML/CSS adequada para informar o usuário e apresentar as opções apropriadas. Nenhuma ação adicional é necessária pelo aplicativo para novos registros.

Obter consentimento dos pais

Dependendo da regulamentação do aplicativo, o consentimento dos pais pode precisar ser concedido por um usuário que é verificado como adulto. O Azure AD B2C não fornece uma experiência para verificar a idade de um indivíduo e, em seguida, permitir que um adulto verificado conceda consentimento dos pais a um menor. Essa experiência deve ser fornecida pelo aplicativo ou outro provedor de serviços.

Veja a seguir um exemplo de um fluxo de usuário para coletar o consentimento dos pais:

1. Uma operação de API do Microsoft Graph identifica o usuário como menor de idade e retorna os dados do usuário ao aplicativo na forma de um token JSON sem assinatura.

2. O aplicativo processa o token JSON e mostra uma tela para o menor, notificando-os de que o consentimento dos pais é necessário e solicitando o consentimento de um pai online.

3. O Azure AD B2C mostra um percurso de entrada no qual o usuário pode entrar normalmente e emite um token para o aplicativo que está definido para incluir legalAgeGroupClassification = "minorWithParentalConsent". O aplicativo coleta o endereço de email do pai e verifica se o pai é um adulto. Para fazer isso, ele usa uma fonte confiável, como um escritório de ID nacional/regional, verificação de licença ou prova de cartão de crédito. Se a verificação for bem-sucedida, o aplicativo solicitará que o menor entre usando o fluxo de usuário do Azure AD B2C. Se o consentimento for negado (por exemplo, se legalAgeGroupClassification = "minorWithoutParentalConsent"), o Azure AD B2C retornará um token JSON (não um logon) ao aplicativo para reiniciar o processo de consentimento. Opcionalmente, é possível personalizar o fluxo de usuário para que um menor ou um adulto possa recuperar o acesso à conta de um menor enviando um código de registro para o endereço de email do menor ou o endereço de email do adulto registrado.

4. O aplicativo oferece uma opção ao menor para revogar o consentimento.

5. Quando o menor ou o adulto revoga o consentimento, a API do Microsoft Graph pode ser usada para alterar consentProvidedForMinor para negado. Como alternativa, o aplicativo pode optar por excluir um menor cujo consentimento foi revogado. Opcionalmente, é possível personalizar o fluxo do usuário para que o menor autenticado (ou pai que está usando a conta do menor) possa revogar o consentimento. O Azure AD B2C registra consentProvidedForMinor como negado.

Para obter mais informações sobre legalAgeGroupClassification, consentProvidedForMinor e ageGroup, consulte o tipo de recurso de usuário. Para obter mais informações sobre atributos personalizados, consulte Usar atributos personalizados para coletar informações sobre seus consumidores. Ao abordar atributos estendidos usando a API do Microsoft Graph, você deve usar a versão longa do atributo, como extension_18b70cf9bb834edd8f38521c2583cd86_dateOfBirth: 2011-01-01T00:00:00Z.

Coletar dados de data de nascimento e país/região

Os aplicativos podem contar com o Azure AD B2C para coletar as informações de data de nascimento (DOB) e país/região de todos os usuários durante o registro. Se essas informações ainda não existirem, o aplicativo poderá solicitá-la ao usuário durante o próximo percurso de autenticação (entrada). Os usuários não podem continuar sem fornecer informações sobre o DOB e o país/região. O Azure AD B2C usa as informações para determinar se o indivíduo é considerado menor de acordo com os padrões regulatórios desse país/região.

Um fluxo de usuário personalizado pode reunir informações de DOB e de país/região e usar a transformação de declarações do Azure AD B2C para determinar o ageGroup e persistir o resultado (ou persistir as informações de país/região e de DOB diretamente) no diretório.

As etapas a seguir mostram a lógica usada para calcular ageGroup a partir da data de nascimento do usuário:

1. Tente localizar o país/região pelo código de país/região na lista. Se o país/região não for encontrado, volte para Padrão.

2. Se o nó MinorConsent estiver presente no elemento de país/região:

   um. Calcule a data em que o usuário deve ter nascido para ser considerado um adulto. Por exemplo, se a data atual for 14 de março de 2015 e MinorConsent for 18, a data de nascimento não deverá ser posterior a 14 de março de 2000.

   b. Compare a data mínima de nascimento com a data de nascimento real. Se a data de nascimento mínima for antes da data de nascimento do usuário, o cálculo retornará Menor como o cálculo da faixa etária.

3. Se o nó MinorNoConsentRequired estiver presente no elemento de país/região, repita as etapas 2a e 2b usando o valor de MinorNoConsentRequired. A saída de 2b retornará MinorNoConsentRequired se a data de nascimento mínima for anterior à data de nascimento do usuário.

4. Se nenhum dos cálculos retornar verdadeiro, o cálculo retornará Adulto.

Se um aplicativo tiver coletado de forma confiável dados do DOB ou país/região por outros métodos, o aplicativo poderá usar a API do Graph para atualizar o registro de usuário com essas informações. Por exemplo:

• Se um usuário for conhecido por ser um adulto, atualize o atributo de diretório ageGroup com um valor de Adulto.
• Se um usuário for conhecido por ser menor, atualize o ageGroup do atributo de diretório com um valor menor e defina consentProvidedForMinor, conforme apropriado.

Regras de cálculo secundárias

O controle de idade envolve dois limites: a idade em que alguém deixa de ser considerado menor e a idade em que um menor deve ter o consentimento dos pais. A tabela a seguir lista as regras de idade usadas para definir um menor e um menor que exijam consentimento.

Capturar contrato de termos de uso

Ao desenvolver seu aplicativo, você normalmente captura a aceitação dos termos de uso dos usuários dentro dos próprios aplicativos, com pouca ou nenhuma participação do diretório do usuário. No entanto, é possível usar um fluxo de usuário do Azure AD B2C para coletar a aceitação dos termos de uso de um usuário, restringir o acesso se a aceitação não for concedida e impor a aceitação de alterações futuras nos termos de uso, com base na data da aceitação mais recente e na data da versão mais recente dos termos de uso.

Os Termos de Uso também podem incluir "Consentimento para compartilhar dados com terceiros". Dependendo de regulamentos locais e regras de negócios, você pode reunir a aceitação de um usuário de ambas as condições combinadas ou permitir que o usuário aceite uma condição e não a outra.

As etapas a seguir descrevem como você pode gerenciar os termos de uso:

1. Registre a aceitação dos termos de uso e a data de aceitação usando a API do Graph e os atributos estendidos. Você pode fazer isso usando fluxos de usuário internos e políticas personalizadas. Recomendamos que você crie e use os atributos extension_termsOfUseConsentDateTime e extension_termsOfUseConsentVersion .

2. Crie uma caixa de seleção necessária rotulada "Aceitar Termos de Uso" e registre o resultado durante a inscrição. Você pode fazer isso usando fluxos de usuário internos e políticas personalizadas.

3. O Azure AD B2C armazena o contrato de termos de uso e a aceitação do usuário. Você pode usar a API do Graph para consultar o status de qualquer usuário, lendo o atributo de extensão utilizado para registrar a resposta (por exemplo, termsOfUseTestUpdateDateTime). Você pode fazer isso usando fluxos de usuário internos e políticas personalizadas.

4. Exigir a aceitação dos termos de uso atualizados comparando a data de aceitação com a data da versão mais recente dos termos de uso. Você só pode comparar as datas usando um fluxo de usuário personalizado. Use o atributo estendido extension_termsOfUseConsentDateTime e compare o valor com a declaração de termsOfUseTextUpdateDateTime. Se a aceitação for velha, force uma nova aceitação exibindo uma tela autoafirmativa. Caso contrário, bloqueie o acesso usando a lógica da política.

5. Exigir aceitação dos termos de uso atualizados comparando o número de versão da aceitação com o número de versão aceito mais recente. Você só pode comparar números de versão usando um fluxo de usuário personalizado. Use o atributo estendido extension_termsOfUseConsentDateTime e compare o valor com a declaração de extension_termsOfUseConsentVersion. Se a aceitação for velha, force uma nova aceitação exibindo uma tela autoafirmativa. Caso contrário, bloqueie o acesso usando a lógica da política.

Você pode capturar a aceitação dos termos de uso nos seguintes cenários:

• Um novo usuário está se inscrevendo. Os termos de uso são exibidos e o resultado da aceitação é armazenado.
• Um usuário está se conectando que já aceitou os termos de uso mais recentes ou ativos. Os termos de uso não são exibidos.
• Um usuário está entrando que ainda não aceitou os termos de uso mais recentes ou ativos. Os termos de uso são exibidos e o resultado da aceitação é armazenado.
• Um usuário está se autenticando que já aceitou uma versão mais antiga dos termos de uso, que foram atualizados para a versão mais recente. Os termos de uso são exibidos e o resultado da aceitação é armazenado.

A imagem a seguir mostra o fluxo de usuário recomendado:

Este é um exemplo de consentimento para termos de uso com base em data em uma declaração. Se a extension_termsOfUseConsentDateTime declaração for mais antiga do que 2025-01-15T00:00:00, force uma nova aceitação verificando a termsOfUseConsentRequired declaração booleana e exibindo uma tela autoafirmativa.

<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>

Este é um exemplo de consentimento para termos de uso com base em versão em uma declaração. Se a declaração extension_termsOfUseConsentVersion não for igual a V1, force uma nova aceitação verificando a declaração booliana termsOfUseConsentRequired e exibindo uma tela autodeclarada.

<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>

Próximas etapas

• Habilite restrição de idade no Azure AD B2C.
• Para saber como excluir e exportar dados do usuário, consulte Gerenciar dados do usuário.
• Para obter um exemplo de política personalizada que implementa um prompt de termos de uso, consulte a política personalizada do A B2C IEF – Inscrever-se e entrar com o prompt "Termos de Uso".