Configurar um fluxo de credenciais de senha do proprietário do recurso no Azure Ative Directory B2C

Artigo
11/08/2023

Antes de começar, use o seletor Escolha um tipo de política para escolher o tipo de política que você está configurando. O Azure Ative Directory B2C oferece dois métodos para definir como os usuários interagem com seus aplicativos: por meio de fluxos de usuário predefinidos ou por meio de políticas personalizadas totalmente configuráveis. As etapas exigidas neste artigo são diferentes para cada método.

No Azure Ative Directory B2C (Azure AD B2C), o fluxo de credenciais de senha do proprietário do recurso (ROPC) é um fluxo de autenticação padrão OAuth. Nesse fluxo, um aplicativo, também conhecido como terceira parte confiável, troca credenciais válidas por tokens. As credenciais incluem um ID de usuário e senha. Os tokens retornados são um token de ID, um token de acesso e um token de atualização.

Aviso

Recomendamos que você não use o fluxo ROPC. Na maioria dos cenários, alternativas mais seguras estão disponíveis e são recomendadas. Esse fluxo requer um grau muito alto de confiança no aplicativo e acarreta riscos que não estão presentes em outros fluxos. Você só deve usar esse fluxo quando outros fluxos mais seguros não forem viáveis.

Notas de fluxo ROPC

No Azure Ative Directory B2C (Azure AD B2C), as seguintes opções são suportadas:

Cliente nativo: a interação do usuário durante a autenticação acontece quando o código é executado em um dispositivo do lado do usuário. O dispositivo pode ser um aplicativo móvel executado em um sistema operacional nativo, como Android e iOS.
Fluxo de cliente público: somente as credenciais do usuário, coletadas por um aplicativo, são enviadas na chamada de API. As credenciais do aplicativo não são enviadas.
Adicionar novas declarações: o conteúdo do token de ID pode ser alterado para adicionar novas declarações.

Os seguintes fluxos não são suportados:

Servidor para servidor: O sistema de proteção de identidade precisa de um endereço IP confiável coletado do chamador (o cliente nativo) como parte da interação. Em uma chamada de API do lado do servidor, apenas o endereço IP do servidor é usado. Se um limite dinâmico de autenticações com falha for excedido, o sistema de proteção de identidade poderá identificar um endereço IP repetido como um invasor.
Fluxo confidencial do cliente: o ID do cliente do aplicativo é validado, mas o segredo do aplicativo não é validado.

Ao usar o fluxo ROPC, considere o seguinte:

O ROPC não funciona quando há qualquer interrupção no fluxo de autenticação que precisa de interação do usuário. Por exemplo, quando uma senha expirou ou precisa ser alterada, a autenticação multifator é necessária ou quando mais informações precisam ser coletadas durante o login (por exemplo, consentimento do usuário).
O ROPC suporta apenas contas locais. Os usuários não podem entrar com provedores de identidade federada como Microsoft, Google+, Twitter, AD-FS ou Facebook.
O Gerenciamento de Sessão, incluindo manter conectado (KMSI), não é aplicável.

Registar uma aplicação

Para registrar uma aplicação no inquilino do AAD B2C, pode utilizar a nossa nova experiência de Registos de aplicações unificada ou a nossa experiência legada de Aplicações (legadas). Saiba mais sobre a nova experiência.

Registos das aplicações
Aplicações (Legado)

Inicie sessão no portal do Azure.
Verifique se você está usando o diretório que contém seu locatário do Azure AD B2C:
1. Selecione o ícone Diretórios + assinaturas na barra de ferramentas do portal.
2. Nas configurações do Portal | Página Diretórios + assinaturas , localize seu diretório do Azure AD B2C na lista Nome do diretório e selecione Alternar.
No portal do Azure, procure e selecione Azure AD B2C
Selecione Registos de aplicações e, em seguida, selecione Novo registo.
Insira um Nome para o aplicativo. Por exemplo, ROPC_Auth_app.
Deixe os outros valores como estão e selecione Registrar.
Registre o ID do aplicativo (cliente) para uso em uma etapa posterior.
Em Gerir, selecione Autenticação.
Selecione Experimentar a nova experiência (se mostrada).
Em Configurações avançadas e na seção Habilitar os seguintes fluxos móveis e de desktop, selecione Sim para tratar o aplicativo como um cliente público. Essa configuração é necessária para o fluxo ROPC.
Selecione Guardar.
No menu à esquerda, selecione Manifesto para abrir o editor de manifesto.
Defina o atributo oauth2AllowImplicitFlow como true:
```
"oauth2AllowImplicitFlow": true,
```
Selecione Guardar.

Criar um fluxo de usuário do proprietário do recurso

Entre no portal do Azure como administrador global do seu locatário do Azure AD B2C.
Se você tiver acesso a vários locatários, selecione o ícone Configurações no menu superior para alternar para seu locatário do Azure AD B2C no menu Diretórios + assinaturas .
No portal do Azure, procure e selecione Azure AD B2C.
Selecione Fluxos de usuário e selecione Novo fluxo de usuário.
Selecione Entrar usando credenciais de senha do proprietário do recurso (ROPC).
Em Versão, certifique-se de que Pré-visualização está selecionado e, em seguida, selecione Criar.
Forneça um nome para o fluxo de usuário, como ROPC_Auth.
Em Declarações de aplicativo, selecione Mostrar mais.
Selecione as declarações de aplicativo que você precisa para seu aplicativo, como Nome para exibição, Endereço de e-mail e Provedor de identidade.
Selecione OK e, em seguida, selecione Criar.

Pré-requisito

Se você não tiver feito isso, saiba mais sobre o pacote inicial de políticas personalizadas em Introdução às políticas personalizadas no Ative Directory B2C.

Criar uma política de proprietário de recursos

Abra o arquivo TrustFrameworkExtensions.xml .

Se ainda não existir, adicione um elemento ClaimsSchema e seus elementos filho como o primeiro elemento sob o elemento BuildingBlocks :

<ClaimsSchema>
  <ClaimType Id="logonIdentifier">
    <DisplayName>User name or email address that the user can use to sign in</DisplayName>
    <DataType>string</DataType>
  </ClaimType>
  <ClaimType Id="resource">
    <DisplayName>The resource parameter passes to the ROPC endpoint</DisplayName>
    <DataType>string</DataType>
  </ClaimType>
  <ClaimType Id="refreshTokenIssuedOnDateTime">
    <DisplayName>An internal parameter used to determine whether the user should be permitted to authenticate again using their existing refresh token.</DisplayName>
    <DataType>string</DataType>
  </ClaimType>
  <ClaimType Id="refreshTokensValidFromDateTime">
    <DisplayName>An internal parameter used to determine whether the user should be permitted to authenticate again using their existing refresh token.</DisplayName>
    <DataType>string</DataType>
  </ClaimType>
</ClaimsSchema>

Após ClaimsSchema, adicione um elemento ClaimsTransformations e seus elementos filho ao elemento BuildingBlocks :

<ClaimsTransformations>
  <ClaimsTransformation Id="CreateSubjectClaimFromObjectID" TransformationMethod="CreateStringClaim">
    <InputParameters>
      <InputParameter Id="value" DataType="string" Value="Not supported currently. Use oid claim." />
    </InputParameters>
    <OutputClaims>
      <OutputClaim ClaimTypeReferenceId="sub" TransformationClaimType="createdClaim" />
    </OutputClaims>
  </ClaimsTransformation>

  <ClaimsTransformation Id="AssertRefreshTokenIssuedLaterThanValidFromDate" TransformationMethod="AssertDateTimeIsGreaterThan">
    <InputClaims>
      <InputClaim ClaimTypeReferenceId="refreshTokenIssuedOnDateTime" TransformationClaimType="leftOperand" />
      <InputClaim ClaimTypeReferenceId="refreshTokensValidFromDateTime" TransformationClaimType="rightOperand" />
    </InputClaims>
    <InputParameters>
      <InputParameter Id="AssertIfEqualTo" DataType="boolean" Value="false" />
      <InputParameter Id="AssertIfRightOperandIsNotPresent" DataType="boolean" Value="true" />
    </InputParameters>
  </ClaimsTransformation>
</ClaimsTransformations>

Localize o elemento ClaimsProvider que tem um DisplayName de Local Account SignIn e adicione o seguinte perfil técnico:

<TechnicalProfile Id="ResourceOwnerPasswordCredentials-OAUTH2">
  <DisplayName>Local Account SignIn</DisplayName>
  <Protocol Name="OpenIdConnect" />
  <Metadata>
    <Item Key="UserMessageIfClaimsPrincipalDoesNotExist">We can't seem to find your account</Item>
    <Item Key="UserMessageIfInvalidPassword">Your password is incorrect</Item>
    <Item Key="UserMessageIfOldPasswordUsed">Looks like you used an old password</Item>
    <Item Key="DiscoverMetadataByTokenIssuer">true</Item>
    <Item Key="ValidTokenIssuerPrefixes">https://sts.windows.net/</Item>
    <Item Key="METADATA">https://login.microsoftonline.com/{tenant}/.well-known/openid-configuration</Item>
    <Item Key="authorization_endpoint">https://login.microsoftonline.com/{tenant}/oauth2/token</Item>
    <Item Key="response_types">id_token</Item>
    <Item Key="response_mode">query</Item>
    <Item Key="scope">email openid</Item>
    <Item Key="grant_type">password</Item>
  </Metadata>
  <InputClaims>
    <InputClaim ClaimTypeReferenceId="logonIdentifier" PartnerClaimType="username" Required="true" DefaultValue="{OIDC:Username}"/>
    <InputClaim ClaimTypeReferenceId="password" Required="true" DefaultValue="{OIDC:Password}" />
    <InputClaim ClaimTypeReferenceId="grant_type" DefaultValue="password" />
    <InputClaim ClaimTypeReferenceId="scope" DefaultValue="openid" />
    <InputClaim ClaimTypeReferenceId="nca" PartnerClaimType="nca" DefaultValue="1" />
    <InputClaim ClaimTypeReferenceId="client_id" DefaultValue="ProxyIdentityExperienceFrameworkAppId" />
    <InputClaim ClaimTypeReferenceId="resource_id" PartnerClaimType="resource" DefaultValue="IdentityExperienceFrameworkAppId" />
  </InputClaims>
  <OutputClaims>
    <OutputClaim ClaimTypeReferenceId="objectId" PartnerClaimType="oid" />
    <OutputClaim ClaimTypeReferenceId="userPrincipalName" PartnerClaimType="upn" />
  </OutputClaims>
  <OutputClaimsTransformations>
    <OutputClaimsTransformation ReferenceId="CreateSubjectClaimFromObjectID" />
  </OutputClaimsTransformations>
  <UseTechnicalProfileForSessionManagement ReferenceId="SM-Noop" />
</TechnicalProfile>

Substitua o DefaultValue de client_id pela ID do aplicativo ProxyIdentityExperienceFramework que você criou no tutorial de pré-requisito. Em seguida, substitua DefaultValue of resource_id pela ID do aplicativo IdentityExperienceFramework que você também criou no tutorial de pré-requisito.

Adicione os seguintes elementos ClaimsProvider com seus perfis técnicos ao elemento ClaimsProviders:

<ClaimsProvider>
  <DisplayName>Azure Active Directory</DisplayName>
  <TechnicalProfiles>
    <TechnicalProfile Id="AAD-UserReadUsingObjectId-CheckRefreshTokenDate">
      <Metadata>
        <Item Key="Operation">Read</Item>
        <Item Key="RaiseErrorIfClaimsPrincipalDoesNotExist">true</Item>
      </Metadata>
      <InputClaims>
        <InputClaim ClaimTypeReferenceId="objectId" Required="true" />
      </InputClaims>
      <OutputClaims>
        <OutputClaim ClaimTypeReferenceId="objectId" />
        <OutputClaim ClaimTypeReferenceId="refreshTokensValidFromDateTime" />
      </OutputClaims>
      <OutputClaimsTransformations>
        <OutputClaimsTransformation ReferenceId="AssertRefreshTokenIssuedLaterThanValidFromDate" />
        <OutputClaimsTransformation ReferenceId="CreateSubjectClaimFromObjectID" />
      </OutputClaimsTransformations>
      <IncludeTechnicalProfile ReferenceId="AAD-Common" />
    </TechnicalProfile>
  </TechnicalProfiles>
</ClaimsProvider>

<ClaimsProvider>
  <DisplayName>Session Management</DisplayName>
  <TechnicalProfiles>
    <TechnicalProfile Id="SM-RefreshTokenReadAndSetup">
      <DisplayName>Trustframework Policy Engine Refresh Token Setup Technical Profile</DisplayName>
      <Protocol Name="None" />
      <OutputClaims>
        <OutputClaim ClaimTypeReferenceId="objectId" />
        <OutputClaim ClaimTypeReferenceId="refreshTokenIssuedOnDateTime" />
      </OutputClaims>
    </TechnicalProfile>
  </TechnicalProfiles>
</ClaimsProvider>

<ClaimsProvider>
  <DisplayName>Token Issuer</DisplayName>
  <TechnicalProfiles>
    <TechnicalProfile Id="JwtIssuer">
      <Metadata>
        <!-- Point to the redeem refresh token user journey-->
        <Item Key="RefreshTokenUserJourneyId">ResourceOwnerPasswordCredentials-RedeemRefreshToken</Item>
      </Metadata>
    </TechnicalProfile>
  </TechnicalProfiles>
</ClaimsProvider>

Adicione um elemento UserJourneys e seus elementos filho ao elemento TrustFrameworkPolicy :

<UserJourney Id="ResourceOwnerPasswordCredentials">
  <PreserveOriginalAssertion>false</PreserveOriginalAssertion>
  <OrchestrationSteps>
    <OrchestrationStep Order="1" Type="ClaimsExchange">
      <ClaimsExchanges>
        <ClaimsExchange Id="ResourceOwnerFlow" TechnicalProfileReferenceId="ResourceOwnerPasswordCredentials-OAUTH2" />
      </ClaimsExchanges>
    </OrchestrationStep>
    <OrchestrationStep Order="2" Type="ClaimsExchange">
      <ClaimsExchanges>
        <ClaimsExchange Id="AADUserReadWithObjectId" TechnicalProfileReferenceId="AAD-UserReadUsingObjectId" />
      </ClaimsExchanges>
    </OrchestrationStep>
    <OrchestrationStep Order="3" Type="SendClaims" CpimIssuerTechnicalProfileReferenceId="JwtIssuer" />
  </OrchestrationSteps>
</UserJourney>
<UserJourney Id="ResourceOwnerPasswordCredentials-RedeemRefreshToken">
  <PreserveOriginalAssertion>false</PreserveOriginalAssertion>
  <OrchestrationSteps>
    <OrchestrationStep Order="1" Type="ClaimsExchange">
      <ClaimsExchanges>
        <ClaimsExchange Id="RefreshTokenSetupExchange" TechnicalProfileReferenceId="SM-RefreshTokenReadAndSetup" />
      </ClaimsExchanges>
    </OrchestrationStep>
    <OrchestrationStep Order="2" Type="ClaimsExchange">
      <ClaimsExchanges>
        <ClaimsExchange Id="CheckRefreshTokenDateFromAadExchange" TechnicalProfileReferenceId="AAD-UserReadUsingObjectId-CheckRefreshTokenDate" />
      </ClaimsExchanges>
    </OrchestrationStep>
    <OrchestrationStep Order="3" Type="SendClaims" CpimIssuerTechnicalProfileReferenceId="JwtIssuer" />
  </OrchestrationSteps>
</UserJourney>

Na página Políticas Personalizadas no seu locatário do Azure AD B2C, selecione Política de Carregamento.
Habilite Substituir a política, se ela existir, e procure e selecione o arquivo TrustFrameworkExtensions.xml arquivo.
Selecione Carregar.

Criar um arquivo de terceira parte confiável

Em seguida, atualize o arquivo de terceira parte confiável que inicia a jornada do usuário que você criou:

Faça uma cópia do arquivo SignUpOrSignin.xml em seu diretório de trabalho e renomeie-o para ROPC_Auth.xml.
Abra o novo arquivo e altere o valor do atributo PolicyId para TrustFrameworkPolicy para um valor exclusivo. O ID da política é o nome da sua política. Por exemplo, B2C_1A_ROPC_Auth.
Altere o valor do atributo ReferenceId em DefaultUserJourney para ResourceOwnerPasswordCredentials.

Altere o elemento OutputClaims para conter apenas as seguintes declarações:

<OutputClaim ClaimTypeReferenceId="sub" />
<OutputClaim ClaimTypeReferenceId="objectId" />
<OutputClaim ClaimTypeReferenceId="displayName" DefaultValue="" />
<OutputClaim ClaimTypeReferenceId="givenName" DefaultValue="" />
<OutputClaim ClaimTypeReferenceId="surname" DefaultValue="" />

Na página Políticas Personalizadas no seu locatário do Azure AD B2C, selecione Política de Carregamento.
Habilite Substituir a política, se ela existir, e procure e selecione o arquivo ROPC_Auth.xml .
Selecione Carregar.

Testar o fluxo ROPC

Use seu aplicativo favorito de desenvolvimento de API para gerar uma chamada de API e revise a resposta para depurar sua política. Construa uma chamada como este exemplo com as seguintes informações como o corpo da solicitação POST:

https://<tenant-name>.b2clogin.com/<tenant-name>.onmicrosoft.com/B2C_1A_ROPC_Auth/oauth2/v2.0/token

Substitua <tenant-name> pelo nome do seu locatário do Azure AD B2C.
Substitua B2C_1A_ROPC_Auth pelo nome completo da política de credenciais de senha do proprietário do recurso.

Key	valor
nome de utilizador	`user-account`
password	`password1`
grant_type	password
âmbito	offline_access OpenID `application-id`
client_id	`application-id`
response_type	token id_token

Substitua user-account pelo nome de uma conta de usuário em seu locatário.
Substitua password1 pela senha da conta de usuário.
Substitua application-id pelo ID do aplicativo do registro ROPC_Auth_app .
Offline_access é opcional se você quiser receber um token de atualização.

A solicitação POST real se parece com o exemplo a seguir:

POST /<tenant-name>.onmicrosoft.com/B2C_1A_ROPC_Auth/oauth2/v2.0/token HTTP/1.1
Host: <tenant-name>.b2clogin.com
Content-Type: application/x-www-form-urlencoded

username=contosouser.outlook.com.ws&password=Passxword1&grant_type=password&scope=openid+bef22d56-552f-4a5b-b90a-1988a7d634ce+offline_access&client_id=bef22d56-552f-4a5b-b90a-1988a7d634ce&response_type=token+id_token

Uma resposta bem-sucedida com acesso offline se parece com o exemplo a seguir:

{
    "access_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsImtpZCI6Ik9YQjNhdTNScWhUQWN6R0RWZDM5djNpTmlyTWhqN2wxMjIySnh6TmgwRlki...",
    "token_type": "Bearer",
    "expires_in": "3600",
    "refresh_token": "eyJraWQiOiJacW9pQlp2TW5pYVc2MUY0TnlfR3REVk1EVFBLbUJLb0FUcWQ1ZWFja1hBIiwidmVyIjoiMS4wIiwiemlwIjoiRGVmbGF0ZSIsInNlciI6Ij...",
    "id_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsImtpZCI6Ik9YQjNhdTNScWhUQWN6R0RWZDM5djNpTmlyTWhqN2wxMjIySnh6TmgwRlki..."
}

Resgatar um token de atualização

Construa uma chamada POST como a mostrada aqui. Use as informações na tabela a seguir como o corpo da solicitação:

https://<tenant-name>.b2clogin.com/<tenant-name>.onmicrosoft.com/B2C_1A_ROPC_Auth/oauth2/v2.0/token

Substitua <tenant-name> pelo nome do seu locatário do Azure AD B2C.
Substitua B2C_1A_ROPC_Auth pelo nome completo da política de credenciais de senha do proprietário do recurso.

Key	valor
grant_type	refresh_token
response_type	id_token
client_id	`application-id`
recurso	`application-id`
refresh_token	`refresh-token`

Substitua application-id pelo ID do aplicativo do registro ROPC_Auth_app .
Substitua refresh-token pelo refresh_token que foi enviado de volta na resposta anterior.

Uma resposta bem-sucedida se parece com o exemplo a seguir:

{
    "access_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsImtpZCI6Ilg1ZVhrNHh5b2pORnVtMWtsMll0djhkbE5QNC1jNTdkTzZRR1RWQndhT...",
    "id_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsImtpZCI6Ilg1ZVhrNHh5b2pORnVtMWtsMll0djhkbE5QNC1jNTdkTzZRR1RWQn...",
    "token_type": "Bearer",
    "not_before": 1533672990,
    "expires_in": 3600,
    "expires_on": 1533676590,
    "resource": "bef2222d56-552f-4a5b-b90a-1988a7d634c3",
    "id_token_expires_in": 3600,
    "profile_info": "eyJ2ZXIiOiIxLjAiLCJ0aWQiOiI1MTZmYzA2NS1mZjM2LTRiOTMtYWE1YS1kNmVlZGE3Y2JhYzgiLCJzdWIiOm51bGwsIm5hbWUiOiJEYXZpZE11IiwicHJlZmVycmVkX3VzZXJuYW1lIjpudWxsLCJpZHAiOiJMb2NhbEFjY291bnQifQ",
    "refresh_token": "eyJraWQiOiJjcGltY29yZV8wOTI1MjAxNSIsInZlciI6IjEuMCIsInppcCI6IkRlZmxhdGUiLCJzZXIiOiIxLjAi...",
    "refresh_token_expires_in": 1209600
}

Resolução de problemas

O aplicativo fornecido não está configurado para permitir o fluxo implícito 'OAuth'

Sintoma - Você executa o fluxo ROPC e recebe a seguinte mensagem: AADB2C90057: O aplicativo fornecido não está configurado para permitir o fluxo implícito 'OAuth'.
Causas possíveis - O fluxo implícito não é permitido para o seu aplicativo.
Resolução: ao criar seu registro de aplicativo no Azure AD B2C, você precisa editar manualmente o manifesto do aplicativo e definir o oauth2AllowImplicitFlow valor da propriedade como true. Depois de configurar a propriedade, pode levar alguns minutos (normalmente não mais de cinco) para que a oauth2AllowImplicitFlow alteração tenha efeito.

Usar um SDK nativo ou App-Auth

O Azure AD B2C atende aos padrões OAuth 2.0 para credenciais de senha de proprietário de recurso de cliente público e deve ser compatível com a maioria dos SDKs de cliente. Para obter as informações mais recentes, consulte SDK de aplicativo nativo para OAuth 2.0 e OpenID Connect implementando práticas recomendadas modernas.

Próximos passos

Baixe exemplos de trabalho que foram configurados para uso com o Azure AD B2C do GitHub, para Android e iOS.

Partilhar via