Partilhar via


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

Importante

A partir de 1º de maio de 2025, o Azure AD B2C não estará mais disponível para compra para novos clientes. Saiba mais nas nossas Perguntas Frequentes.

Antes de começar, use o seletor Escolha um tipo de política na parte superior desta página 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.

Advertência

Recomendamos que 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 de cliente da aplicação é validado, mas o segredo da aplicação não é validado.

Ao usar o fluxo ROPC, considere as seguintes limitações:

  • 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 expira 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+, X, AD-FS ou Facebook.
  • Gestão de Sessão, incluindo manter-me conectado (KMSI), não é aplicável.

Registar uma candidatura

Para registrar um aplicativo em seu locatário do Azure AD B2C, você pode usar nossa nova experiência unificada de registros de aplicativos ou nossa experiência de aplicativos herdados (legados). Saiba mais sobre a nova experiência.

  1. Inicie sessão no portal Azure.
  2. 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.
  3. No portal do Azure, procure e selecione Azure AD B2C
  4. Selecione Registos de aplicaçõese, em seguida, selecione Novo registo.
  5. Insira um Nome para o aplicativo. Por exemplo, ROPC_Auth_app.
  6. Deixe os outros valores como estão e selecione Registrar.
  7. Registre o ID do aplicativo (cliente) para uso em uma etapa posterior.
  8. Em Gerir, selecione Autenticação.
  9. Selecione Experimentar a nova experiência (se mostrada).
  10. 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.
  11. Selecione Guardar.
  12. No menu à esquerda, selecione Manifesto para abrir o editor de manifesto.
  13. Defina o atributo oauth2AllowImplicitFlow como true. Se o atributo não existir, adicione-o:
    "oauth2AllowImplicitFlow": true,
    
  14. Selecione Guardar.

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

  1. Entre no portal do Azure como o Administrador de Fluxo de Usuário de ID Externa do seu locatário do Azure AD B2C.
  2. Se tiver acesso a vários inquilinos, selecione o ícone Definições no menu superior para mudar para o inquilino do Azure AD B2C no menu Diretórios + subscrições.
  3. No portal do Azure, procure e selecione Azure AD B2C.
  4. Selecione Fluxos de usuário e selecione Novo fluxo de usuário.
  5. Selecione Entrar usando credenciais de senha do proprietário do recurso (ROPC).
  6. Em Versão, certifique-se de que Pré-visualização está selecionado e, em seguida, selecione Criar.
  7. Forneça um nome para o fluxo de usuário, como ROPC_Auth.
  8. Em Declarações de aplicativo, selecione Mostrar mais.
  9. 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.
  10. Selecione OK e, em seguida, selecione Criar.

Pré-requisito

Se você não tiver feito isso, saiba como usar 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

  1. Abra o arquivo TrustFrameworkExtensions.xml .

  2. No elemento BuildingBlocks , localize o elemento ClaimsSchema e adicione os seguintes tipos de declaração:

    <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>
    
  3. 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>
    
  4. 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 de resource_id pela ID do aplicativo IdentityExperienceFramework que você também criou no tutorial de pré-requisito.

  5. 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>
    
  6. 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>
    
  7. Na página Políticas Personalizadas no seu locatário do Azure AD B2C, selecione Política de Carregamento.

  8. Habilite Sobrescrever a política, se ela existir, e, em seguida, navegue até e selecione o ficheiro TrustFrameworkExtensions.xml.

  9. 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:

  1. Faça uma cópia de SignUpOrSignin.xml arquivo em seu diretório de trabalho e renomeie-o para ROPC_Auth.xml.

  2. Abra o novo arquivo e altere o valor do atributo PolicyId para TrustFrameworkPolicy para um valor exclusivo. O identificador da política é o nome da sua política. Por exemplo, B2C_1A_ROPC_Auth.

  3. Altere o valor do atributo ReferenceId em DefaultUserJourney para ResourceOwnerPasswordCredentials.

  4. 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="" />
    
  5. Na página Políticas Personalizadas no seu locatário do Azure AD B2C, selecione Política de Carregamento.

  6. Habilite Substituir a política, se existir, e procure e selecione o ficheiro ROPC_Auth.xml.

  7. 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.
Chave Valor
nome de utilizador user-account
palavra-passe password1
tipo de concessão palavra-passe
Alcance offline_access OpenID application-id
ID do cliente application-id
tipo_de_resposta 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 pela 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+00001111-aaaa-2222-bbbb-3333cccc4444+offline_access&client_id=00001111-aaaa-2222-bbbb-3333cccc4444&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.
Chave Valor
tipo de concessão token de atualização
tipo_de_resposta id_token (token de identificação)
ID do cliente application-id
recurso application-id
token de atualização refresh-token
  • Substitua application-id pela 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
}

Soluçã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 oauth2AllowImplicitFlow propriedade, pode levar alguns minutos (normalmente não mais do que cinco) para que a alteração entre em vigor.

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.