Compartilhar via


Configurar o cadastro e login com uma conta do GitHub usando o Azure Active 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 em nossas perguntas frequentes.

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

Observação

Esse recurso está em versão prévia pública.

Importante

A partir de maio de 2021, o GitHub anunciou uma alteração que afeta sua federação de política personalizada do Azure AD B2C. Devido à alteração, adicione <Item Key="BearerTokenTransmissionMethod">AuthorizationHeader</Item> metadados ao seu perfil técnico do GitHub. Para obter mais informações, consulte Preterindo a autenticação de API por meio de parâmetros de consulta.

Pré-requisitos

Criar um aplicativo OAuth do GitHub

Para habilitar a entrada com uma conta do GitHub no Azure AD B2C (Azure Active Directory B2C), você precisa criar um aplicativo no portal do Desenvolvedor do GitHub . Para obter mais informações, consulte Criando um aplicativo OAuth. Se você ainda não tiver uma conta do GitHub, poderá se inscrever em https://www.github.com/.

  1. Faça login no GitHub Developer com suas credenciais do GitHub.
  2. Selecione Aplicativos OAuth e selecione Novo Aplicativo OAuth.
  3. Insira um nome de aplicativo e sua URL da home page.
  4. Para a URL de retorno de chamada da autorização, insira https://your-tenant-name.b2clogin.com/your-tenant-name.onmicrosoft.com/oauth2/authresp. Se você usa um domínio personalizado, insira https://your-domain-name/your-tenant-name.onmicrosoft.com/oauth2/authresp. Substitua your-domain-name pelo domínio personalizado e your-tenant-name pelo nome do locatário. Use todas as letras minúsculas ao inserir o nome do locatário mesmo que o locatário seja definido com letras maiúsculas no Azure AD B2C.
  5. Clique em Registrar aplicativo.
  6. Copie os valores da ID do Cliente e do Segredo do Cliente. Você precisará delas para adicionar o provedor de identidade ao locatário.

Configurar o GitHub como um provedor de identidade

  1. Entre no portal do Azure com uma conta que tenha pelo menos privilégios de Administrador do Provedor de Identidade Externo.
  2. 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.
  3. Escolha Todos os serviços no canto superior esquerdo do portal do Azure, pesquise e selecione O Azure AD B2C.
  4. Selecione provedores de identidade e, em seguida, selecione GitHub (versão prévia).
  5. Insira um Nome. Por exemplo, GitHub.
  6. Para a ID do cliente, insira a ID do cliente do aplicativo GitHub que você criou anteriormente.
  7. Para o segredo do cliente, insira o Segredo do Cliente que você gravou.
  8. Clique em Salvar.

Adicionar o provedor de identidade do GitHub a um fluxo de usuário

Neste ponto, o provedor de identidade do GitHub foi configurado, mas ainda não está disponível em nenhuma das páginas de entrada. Para adicionar o provedor de identidade do GitHub a um fluxo de usuário:

  1. No locatário do Azure AD B2C, selecione Fluxos dos usuários.
  2. Clique no fluxo de usuário que você deseja adicionar ao provedor de identidade do GitHub.
  3. Nos provedores de identidade social, selecione GitHub.
  4. Clique em Salvar.
  5. Para testar a política, selecione Executar fluxo de usuário.
  6. Em Aplicativo, selecione o aplicativo Web denominado testapp1 registrado anteriormente. A URL de resposta deve mostrar https://jwt.ms.
  7. Selecione o botão Executar fluxo de usuário.
  8. Na página de inscrição ou entrada, selecione GitHub para entrar com a conta do GitHub.

Se o processo de entrada for bem-sucedido, seu navegador será redirecionado para https://jwt.ms, que exibe o conteúdo do token retornado pelo Azure AD B2C.

Criar uma chave de política

Você precisa armazenar o segredo do cliente que registrou anteriormente no seu locatário do Azure AD B2C.

  1. Entre no portal do Azure.
  2. 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.
  3. Escolha Todos os serviços no canto superior esquerdo do Portal do Azure, pesquise Azure AD B2C e selecione-o.
  4. Na página Visão geral, selecione Identity Experience Framework.
  5. Selecione Chaves de Política e, em seguida, selecione Adicionar.
  6. Para Opções, escolha Manual.
  7. Insira um Nome para a chave de política. Por exemplo, GitHubSecret. O prefixo B2C_1A_ é adicionado automaticamente ao nome da chave.
  8. Em Segredo, insira o segredo do cliente que você gravou anteriormente.
  9. Para uso de chave, selecione Signature.
  10. Clique em Criar.

Configurar o GitHub como um provedor de identidade

Para permitir que os usuários entrem usando uma conta do GitHub, defina a conta como um provedor de declarações com o qual o Azure AD B2C pode se comunicar por meio de um ponto de extremidade. O endpoint fornece um conjunto de declarações que são usadas pelo Azure AD B2C para verificar se um usuário específico foi autenticado.

Você pode definir uma conta do GitHub como um provedor de declarações adicionando-a ao elemento ClaimsProviders no arquivo de extensão da política.

  1. Abra TrustFrameworkExtensions.xml.

  2. Localize o elemento ClaimsProviders. Se ele não existir, adicione-o sob o elemento raiz.

  3. Adicione um novo ClaimsProvider da seguinte maneira:

    <ClaimsProvider>
      <Domain>github.com</Domain>
      <DisplayName>GitHub</DisplayName>
      <TechnicalProfiles>
        <TechnicalProfile Id="GitHub-OAuth2">
          <DisplayName>GitHub</DisplayName>
          <Protocol Name="OAuth2" />
          <Metadata>
            <Item Key="ProviderName">github.com</Item>
            <Item Key="authorization_endpoint">https://github.com/login/oauth/authorize</Item>
            <Item Key="AccessTokenEndpoint">https://github.com/login/oauth/access_token</Item>
            <Item Key="ClaimsEndpoint">https://api.github.com/user</Item>
            <Item Key="HttpBinding">GET</Item>
            <Item Key="scope">read:user user:email</Item>
            <Item Key="UsePolicyInRedirectUri">0</Item>
            <Item Key="BearerTokenTransmissionMethod">AuthorizationHeader</Item>  
            <Item Key="UserAgentForClaimsExchange">CPIM-Basic/{tenant}/{policy}</Item>
            <!-- Update the Client ID below to the Application ID -->
            <Item Key="client_id">Your GitHub application ID</Item>
          </Metadata>
          <CryptographicKeys>
            <Key Id="client_secret" StorageReferenceId="B2C_1A_GitHubSecret"/>
          </CryptographicKeys>
          <OutputClaims>
            <OutputClaim ClaimTypeReferenceId="displayName" PartnerClaimType="name" />
            <OutputClaim ClaimTypeReferenceId="email" PartnerClaimType="email" />
            <OutputClaim ClaimTypeReferenceId="numericUserId" PartnerClaimType="id" />
            <OutputClaim ClaimTypeReferenceId="issuerUserId" />
            <OutputClaim ClaimTypeReferenceId="identityProvider" DefaultValue="github.com" AlwaysUseDefaultValue="true" />
            <OutputClaim ClaimTypeReferenceId="authenticationSource" DefaultValue="socialIdpAuthentication" AlwaysUseDefaultValue="true" />
          </OutputClaims>
          <OutputClaimsTransformations>
            <OutputClaimsTransformation ReferenceId="CreateIssuerUserId" />
            <OutputClaimsTransformation ReferenceId="CreateRandomUPNUserName"/>
            <OutputClaimsTransformation ReferenceId="CreateUserPrincipalName"/>
            <OutputClaimsTransformation ReferenceId="CreateAlternativeSecurityId"/>
            <OutputClaimsTransformation ReferenceId="CreateSubjectClaimFromAlternativeSecurityId"/>
          </OutputClaimsTransformations>
          <UseTechnicalProfileForSessionManagement ReferenceId="SM-SocialLogin" />
        </TechnicalProfile>
      </TechnicalProfiles>
    </ClaimsProvider>
    
  4. Defina client_id para a ID do aplicativo do registro do aplicativo.

  5. Salve o arquivo.

Adicionar transformações de declarações

O perfil técnico do GitHub requer que as transformações de declaração CreateIssuerUserId sejam adicionadas à lista de ClaimsTransformations. Se você não tiver um elemento ClaimsTransformations definido em seu arquivo, adicione os elementos XML pai, conforme mostrado abaixo. As transformações de declarações também precisam de um novo tipo de declaração definido chamado numericUserId.

  1. Pesquise o elemento BuildingBlocks . Se o elemento não existir, adicione-o.
  2. Localize o elemento ClaimsSchema . Se o elemento não existir, adicione-o.
  3. Adicione a declaração numericUserId ao elemento ClaimsSchema .
  4. Localize o elemento ClaimsTransformations . Se o elemento não existir, adicione-o.
  5. Adicione as transformações de declarações CreateIssuerUserId ao elemento ClaimsTransformations.
<BuildingBlocks>
  <ClaimsSchema>
    <ClaimType Id="numericUserId">
      <DisplayName>Numeric user Identifier</DisplayName>
      <DataType>long</DataType>
    </ClaimType>
  </ClaimsSchema>
  <ClaimsTransformations>
    <ClaimsTransformation Id="CreateIssuerUserId" TransformationMethod="ConvertNumberToStringClaim">
      <InputClaims>
        <InputClaim ClaimTypeReferenceId="numericUserId" TransformationClaimType="inputClaim" />
      </InputClaims>
      <OutputClaims>
        <OutputClaim ClaimTypeReferenceId="issuerUserId" TransformationClaimType="outputClaim" />
      </OutputClaims>
    </ClaimsTransformation>
  </ClaimsTransformations>
</BuildingBlocks>

Adicione um percurso de usuário

Neste ponto, o provedor de identidade foi configurado, mas ainda não está disponível em nenhuma das páginas de entrada. Se você não tiver seu próprio percurso de usuário personalizado, crie a duplicata de um percurso de usuário de um modelo existente; caso contrário, passe para a próxima etapa.

  1. Abra o arquivo TrustFrameworkBase.xml do starter pack.
  2. Localize e copie todo o conteúdo do elemento UserJourney que inclui Id="SignUpOrSignIn".
  3. Abra o TrustFrameworkExtensions.xml e localize o elemento UserJourneys. Se o elemento não existir, adicione um.
  4. Cole todo o conteúdo do elemento UserJourney que você copiou como filho do elemento UserJourneys.
  5. Renomeie a ID do percurso de usuário. Por exemplo, Id="CustomSignUpSignIn".

Adicione o provedor de identidade a um percurso de usuário

Agora que você tem um percurso de usuário, adicione a ele o novo provedor de identidade. Primeiro, adicione um botão de entrada e, em seguida, vincule o botão a uma ação. A ação é o perfil técnico criado anteriormente.

  1. No percurso de usuário, localize o elemento da etapa de orquestração que inclui Type="CombinedSignInAndSignUp" ou Type="ClaimsProviderSelection". Normalmente é a primeira etapa de orquestração. O elementoClaimsProviderSelectionscontém uma lista de provedores de identidade que um usuário pode usar para se conectar. A ordem dos elementos controla a ordem dos botões de entrada apresentados para o usuário. Adicione um elemento XML ClaimsProviderSelection. Defina o valor de TargetClaimsExchangeId com um nome amigável.

  2. Na próxima etapa de orquestração, adicione um elemento ClaimsExchange. Defina a ID como o valor da ID de troca de declarações de destino. Atualize o valor de TechnicalProfileReferenceId para a ID do perfil técnico você já criou.

O XML a seguir demonstra as duas primeiras etapas de orquestração de um percurso do usuário com o provedor de identidade:

<OrchestrationStep Order="1" Type="CombinedSignInAndSignUp" ContentDefinitionReferenceId="api.signuporsignin">
  <ClaimsProviderSelections>
    ...
    <ClaimsProviderSelection TargetClaimsExchangeId="GitHubExchange" />
  </ClaimsProviderSelections>
  ...
</OrchestrationStep>

<OrchestrationStep Order="2" Type="ClaimsExchange">
  ...
  <ClaimsExchanges>
    <ClaimsExchange Id="GitHubExchange" TechnicalProfileReferenceId="GitHub-OAuth2" />
  </ClaimsExchanges>
</OrchestrationStep>

Configurar a política de terceira parte confiável

A política de terceira parte confiável, por exemplo SignUpSignIn.xml, especifica a jornada do usuário que o Azure AD B2C será executado. Localize o elemento DefaultUserJourney na terceira parte confiável. Atualize a ReferenceId para corresponder à ID do percurso do usuário, na qual você adicionou o provedor de identidade.

No exemplo a seguir, para o percurso do CustomSignUpSignIn usuário, o ReferenceId é definido como CustomSignUpSignIn:

<RelyingParty>
  <DefaultUserJourney ReferenceId="CustomSignUpSignIn" />
  ...
</RelyingParty>

Carregar a política personalizada

  1. Entre no portal do Azure.
  2. Selecione o ícone Diretório + Assinatura na barra de ferramentas do portal e selecione o diretório que contém o locatário do Azure AD B2C.
  3. No portal do Azure, pesquise e selecione Azure AD B2C.
  4. Em Políticas, selecione Identity Experience Framework.
  5. Selecione Carregar política personalizadae, em seguida, carregue os dois arquivos de política que você alterou, na seguinte ordem: a política de extensão, por exemplo TrustFrameworkExtensions.xml, a política de terceira parte confiável, como SignUpSignIn.xml.

Testar sua política personalizada

  1. Selecione a política de terceira parte confiável, por exemplo, B2C_1A_signup_signin.
  2. Em Aplicativo, selecione o aplicativo Web que você registrou anteriormente. A URL de resposta deve mostrar https://jwt.ms.
  3. Clique no botão Executar agora.
  4. Na página de inscrição ou entrada, selecione GitHub para entrar com a conta do GitHub.

Se o processo de entrada for bem-sucedido, seu navegador será redirecionado para https://jwt.ms, que exibe o conteúdo do token retornado pelo Azure AD B2C.

Próximas etapas