Partilhar via

Configurar o registo e o início de sessão com uma conta do GitHub utilizando 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 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.

Observação

Este recurso está em pré-visualização pública.

Importante

A partir de maio de 2021, o GitHub anunciou uma alteração que afeta sua federação de políticas personalizadas 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 Substituir a autenticação de API por meio de parâmetros de consulta.

Pré-requisitos

Criar um aplicativo GitHub OAuth

Para habilitar o logon com uma conta do GitHub no Azure Ative Directory B2C (Azure AD 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 tem uma conta no GitHub, pode se inscrever em https://www.github.com/.

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

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 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. Escolha Todos os serviços no canto superior esquerdo do portal do Azure, procure e selecione Azure AD B2C.
  4. Selecione Provedores de identidade e, em seguida, selecione GitHub (Visualização).
  5. Insira um Nome. Por exemplo, o 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. Selecione Guardar.

Adicionar o provedor de identidade 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 login. Para adicionar o provedor de identidade GitHub a um fluxo de usuário:

  1. Em seu locatário do Azure AD B2C, selecione Fluxos de usuário.
  2. Clique no fluxo de utilizador ao qual pretende adicionar o fornecedor de identidade GitHub.
  3. Em Provedores de identidade social, selecione GitHub.
  4. Selecione Guardar.
  5. Para testar sua política, selecione Executar fluxo de usuário.
  6. Em Application, selecione o aplicativo Web chamado testapp1 que você registrou anteriormente. O URL de resposta deve mostrar https://jwt.ms.
  7. Selecione o botão Executar fluxo de utilizador.
  8. Na página de inscrição ou login, 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 você já registrou na sua instância do Azure AD B2C.

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

Configurar o GitHub como um provedor de identidade

Para permitir que os utilizadores entrem usando uma conta de GitHub, você precisa definir 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 utilizadas pelo Azure AD B2C para verificar se um utilizador 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 sua política.

  1. Abra o TrustFrameworkExtensions.xml.

  2. Encontre o elemento ClaimsProviders. Se 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 o ID do aplicativo a partir do registro do aplicativo.

  5. Salve o arquivo.

Adicionar as transformações de reivindicaçõ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. Procure 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 reivindicaçõ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>

Adicionar uma jornada do utilizador

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 sua própria jornada de usuário personalizada, crie uma duplicata de uma jornada de usuário de modelo existente, caso contrário, continue para a próxima etapa.

  1. Abra o arquivo TrustFrameworkBase.xml do pacote inicial.
  2. Encontre e copie todo o conteúdo do elemento UserJourney que contém 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 o identificador da jornada do utilizador. Por exemplo, Id="CustomSignUpSignIn".

Adicionar o provedor de identidade a um percurso do utilizador

Agora que você tem uma jornada do usuário, adicione o novo provedor de identidade à jornada do usuário. Primeiro, adicione um botão de início de sessão e, em seguida, associe o botão a uma ação. A ação é o perfil técnico que tu criaste anteriormente.

  1. Encontre o elemento da etapa de orquestração que inclui Type="CombinedSignInAndSignUp" ou Type="ClaimsProviderSelection" na jornada do utilizador. Geralmente é o primeiro passo da orquestração. O elemento ClaimsProviderSelections contém uma lista de provedores de identidade com os quais um usuário pode entrar. A ordem dos elementos controla a ordem dos botões de entrada apresentados ao usuário. Adicione um ClaimsProviderSelection elemento XML. Defina o valor de TargetClaimsExchangeId como um nome amigável.

  2. Na próxima etapa de orquestração, adicione um elemento ClaimsExchange. Defina o Id como o valor do ID de troca de declarações de destino. Atualize o valor de TechnicalProfileReferenceId para o Id do perfil técnico criado anteriormente.

O XML a seguir demonstra as duas primeiras etapas de orquestração de uma jornada 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 da parte confiadora

A política de entidade confiável, por exemplo, SignUpSignIn.xml, especifica a experiência do utilizador que o Azure AD B2C executará. Encontre o elemento DefaultUserJourney na terceira parte confiável. Atualize o ReferenceId para corresponder ao ID de trajetória do utilizador, em que adicionou o fornecedor de identidade.

No exemplo seguinte, para o percurso do CustomSignUpSignIn utilizador, o ReferenceId é configurado como CustomSignUpSignIn:

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

Carregar a política personalizada

  1. Inicie sessão no portal Azure.
  2. Selecione o ícone Diretório + Assinatura na barra de ferramentas do portal e selecione o diretório que contém seu locatário do Azure AD B2C.
  3. No portal do Azure, procure e selecione Azure AD B2C.
  4. Em Políticas, selecione Identity Experience Framework.
  5. Selecione Carregar Política Personalizada e, em seguida, carregue os dois ficheiros de política que alterou, pela seguinte ordem: a política de extensão, por exemplo TrustFrameworkExtensions.xml, e, em seguida, a política de entidade confiadora, como SignUpSignIn.xml.

Testar sua política personalizada

  1. Selecione sua política de terceira parte confiável, por exemplo B2C_1A_signup_signin.
  2. Em Aplicativo, selecione um aplicativo Web que você registrou anteriormente. O URL de resposta deve mostrar https://jwt.ms.
  3. Selecione o botão Executar agora .
  4. Na página de inscrição ou login, 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óximos passos