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

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

• Identificar menores de idade e controlar o acesso do utilizador à sua aplicação.
• Exigir o consentimento dos pais para que os menores utilizem as suas aplicações.
• Recolha de dados de nascimento e país/região dos utilizadores.
• Obtenção de um acordo de termos de uso e condicionamento do acesso.

Controlar acessos menores

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

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

• Enviar um id_token JWT assinado de volta para o aplicativo: o usuário é registrado no diretório e um token é retornado ao aplicativo. A seguir, a aplicação prossegue com a aplicação de regras de negócio. Por exemplo, o pedido pode prosseguir com um processo de consentimento parental. Para usar este método, escolha receber as declarações ageGroup e consentProvidedForMinor da aplicação.

• Enviar um token JSON não assinado para a aplicação: o Azure AD B2C notifica a aplicação de que o utilizador é menor de idade e fornece o estado do consentimento parental do utilizador. A seguir, a aplicação prossegue com a aplicação de regras de negócio. 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, e-mail, ageGroup e consentProvidedForMinor.

• Bloquear o utilizador: se um utilizador for menor de idade e o consentimento parental não tiver sido fornecido, o Azure AD B2C pode notificar o utilizador de que está bloqueado. Nenhum token é emitido, o acesso é bloqueado e a conta de usuário não é criada durante uma jornada 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. Não é necessária qualquer outra medida por parte da aplicação para novos registos.

Obter o consentimento dos pais

Dependendo da regulamentação da aplicação, o consentimento parental pode ter de ser concedido por um utilizador que seja 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 o consentimento parental a um menor. Esta experiência deve ser fornecida pela aplicação ou por outro prestador de serviços.

Segue-se um exemplo de um fluxo de utilizadores para recolher o consentimento parental:

1. Uma operação da API do Microsoft Graph identifica o usuário como um menor e retorna os dados do usuário para o aplicativo na forma de um token JSON não assinado.

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

3. O Azure AD B2C mostra um processo de início de sessão em que o utilizador pode autenticar-se normalmente e emite um token para a aplicação definida para incluir legalAgeGroupClassification = "minorWithParentalConsent". O aplicativo coleta o endereço de e-mail do pai e verifica se o pai é um adulto. Para fazer isso, ele usa uma fonte confiável, como um escritório de identificação 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 utilizadores para que um menor ou um adulto possa recuperar o acesso à conta de um menor enviando um código de registo para o endereço de e-mail do menor ou para o endereço de e-mail do adulto registado.

4. A aplicação oferece ao menor a opção de 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 denied. Em alternativa, o pedido pode optar por eliminar um menor cujo consentimento tenha sido revogado. Opcionalmente, é possível personalizar o fluxo de usuários para que o menor autenticado (ou o 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 Tipo de recurso do usuário. Para obter mais informações sobre atributos personalizados, consulte Usar atributos personalizados para coletar informações sobre seus consumidores. Quando você aborda 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.

Recolha de dados sobre a data de nascimento e o país/região

Os aplicativos podem confiar no Azure AD B2C para coletar a data de nascimento (DOB) e as informações de país/região de todos os usuários durante o registro. Se essas informações ainda não existirem, o aplicativo poderá solicitá-las ao usuário durante a próxima jornada de autenticação (login). Os usuários não podem prosseguir sem fornecer suas informações de DOB e 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 coletar informações de DOB e país/região e usar a transformação de declarações do Azure AD B2C para determinar o grupo etário e persistir o resultado (ou persistir as informações de DOB e país/região 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 encontrar o país/região pelo código do 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 país/região:

   a) 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 o 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 mínima de nascimento for anterior à data de nascimento do usuário, o cálculo retornará Minor como o cálculo da faixa etária.

3. Caso o nó MinorNoConsentRequired esteja presente no elemento país/região, repita os passos 2a e 2b utilizando o valor de MinorNoConsentRequired. A saída de 2b retorna MinorNoConsentRequired se a data mínima de nascimento for anterior à data de nascimento do usuário.

4. Se nenhum dos cálculos retornar true, o cálculo retornará Adult.

Se um aplicativo tiver coletado dados de DOB ou país/região de forma confiável por outros métodos, o aplicativo poderá usar a API do Graph para atualizar o registro do 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 de idade, atualize o atributo de diretório ageGroup com um valor de Minor e defina consentProvidedForMinor, conforme apropriado.

Regras de cálculo menores

O limite de idade envolve dois valores etários: a idade em que alguém deixa de ser considerado menor e a idade em que o menor tem de ter o consentimento dos pais. A tabela a seguir lista as regras de idade que são usadas para definir um menor e um menor que requer consentimento.

Contrato de termos de uso do Capture

Quando você desenvolve seu aplicativo, normalmente captura a aceitação dos usuários dos termos de uso em seus aplicativos com nenhuma, ou apenas pequena, participação do diretório de usuários. É possível, no entanto, usar um fluxo de usuário do Azure AD B2C para reunir a aceitação dos termos de uso por um usuário, restringir o acesso se a aceitação não for concedida e impor a aceitação de futuras alterações aos 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 dos regulamentos locais e das regras de negócio, pode recolher a aceitação de um utilizador de ambas as condições combinadas ou pode permitir que o utilizador 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 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 obrigatória chamada "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 extension usado para registrar a resposta (por exemplo, ler termosOfUseTestUpdateDateTime). Você pode fazer isso usando fluxos de usuário internos e políticas personalizadas.

4. Exigir a aceitação dos termos de utilização atualizados, comparando a data de aceitação com a data da versão mais recente dos termos de utilização. Você pode comparar as datas somente 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 antiga, obrigue uma nova aceitação ao exibir um ecrã de confirmação. Caso contrário, bloqueie o acesso usando a lógica de política.

5. Exigir a aceitação dos termos de utilização atualizados, comparando o número da versão da aceitação com o número da versão aceite mais recente. Você pode comparar números de versão somente 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 antiga, obrigue uma nova aceitação ao exibir um ecrã de confirmação. Caso contrário, bloqueie o acesso usando a lógica de 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.
• Está a iniciar sessão um utilizador que aceitou previamente os termos de utilização mais recentes ou ativos. Os termos de uso não são exibidos.
• Está a iniciar sessão um utilizador que ainda não aceitou os termos de utilização mais recentes ou ativos. Os termos de uso são exibidos e o resultado da aceitação é armazenado.
• Está a iniciar sessão um utilizador que já aceitou uma versão mais antiga dos termos de utilização, que agora são 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:

Segue-se um exemplo de um consentimento de termos de utilização com base na data numa reclamação. Se a reivindicação extension_termsOfUseConsentDateTime for mais antiga que 2025-01-15T00:00:00, force uma nova aceitação verificando a reivindicação booleana termsOfUseConsentRequired e exibindo um ecrã auto-declarado.

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

Segue-se um exemplo de um consentimento de termos de utilização baseados na versão numa reclamação. Se a extension_termsOfUseConsentVersion reivindicação não for igual a V1, obrigue a nova aceitação verificando a termsOfUseConsentRequired reivindicação booleana e exibindo uma tela de autoafirmação.

<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óximos passos

• Habilite a 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 aviso de termos de uso, veja Uma política personalizada B2C IEF - Registar e Iniciar Sessão com aviso 'Termos de Uso'.