Nesse caso, use um GitHub App
Se possível, crie um GitHub App em vez de um OAuth app. Em geral, os GitHub Apps são mais indicados que os OAuth apps. Os GitHub Apps usam permissões refinadas, dão ao usuário mais controle sobre quais repositórios o aplicativo pode acessar e usam tokens de curta duração. Essas propriedades podem aprimorar a segurança do aplicativo, limitando o dano possível decorrente do vazamento das credenciais.
Assim como os OAuth apps, os GitHub Apps ainda podem usar o OAuth 2.0 e gerar um tipo de token OAuth (chamado de token de acesso do usuário) para realizar ações em nome de um usuário. No entanto, os GitHub Apps também podem agir independentemente de um usuário.
Para saber mais sobre GitHub Apps, confira Sobre a criação de Aplicativos do GitHub.
Para saber mais sobre a migração de um OAuth app existente para um GitHub App, confira Migrar aplicativos OAuth para aplicativos GitHub.
Usar escopos mínimos
O OAuth app só deve solicitar os escopos necessários para que o aplicativo execute a funcionalidade pretendida. Se algum token do aplicativo for comprometido, isso limitará a quantidade de danos ocorridos. Para saber mais, confira Autorizar aplicativos OAuth.
Autorizar de forma completa e duradoura
Depois de conectar um usuário, os desenvolvedores de aplicativos devem executar etapas adicionais para garantir que o usuário tenha acesso aos dados em seu sistema. Cada login requer novas verificações sobre suas associações, acesso e seu status de SSO atual.
Use o id durável e exclusivo para armazenar o usuário
Quando um usuário inicia uma sessão e faz ações em seu aplicativo, você precisa lembrar qual foi o usuário fez a ação para conceder a ele acesso aos mesmos recursos a próxima vez que ele iniciar uma sessão.
Para armazenar usuários em seu banco de dados corretamente, sempre use a id do usuário. Esse valor nunca é alterado para o usuário nem é usado para apontar para um usuário diferente, assim, garante que você esteja fornecendo acesso ao usuário pretendido. Você pode encontrar a id do usuário com o ponto de extremidade de API REST GET /user. Confira "Pontos de extremidade de API REST para usuários".
Se você armazenar referências a repositórios, organizações e empresas, também use a id deles para garantir que seus links para eles permaneçam exatos.
Nunca use identificadores que possam mudar ao longo do tempo, incluindo identificadores de usuário, slugs de organização ou endereços de email.
Validar o acesso da organização para cada nova autenticação
Ao usar um token de acesso do usuário, você deve acompanhar para quais organizações o token está autorizado. Se uma organização usar SSO SAML e um usuário não tiver feito SSO SAML, o token de acesso do usuário não terá acesso a essa organização. Você pode usar o ponto de extremidade da API REST GET /user/installations para verificar a quais organizações um token de acesso de usuário tem acesso. Se o usuário não estiver autorizado a acessar uma organização, você deverá impedir seu acesso aos dados pertencentes à organização dentro do seu aplicativo até que ele faça SSO SAML. Para obter mais informações, confira "Pontos de extremidade da API REST para instalações do GitHub App".
Armazenar dados do usuário com contextos organizacionais e corporativos
Além de rastrear a identidade do usuário por meio do campo id, você deve reter dados para a organização ou empresa em que cada usuário está operando. Isso ajudará a garantir que você não vaze informações confidenciais se um usuário mudar de função.
Por exemplo:
- Um usuário está na organização
Mona, que exige SSO SAML, e inicia uma sessão do seu aplicativo depois de executar o SSO. Seu aplicativo agora tem acesso a tudo o que o usuário faz dentro doMona. - O usuário extrai um monte de código de um repositório em
Monae salva em seu aplicativo para análise. - Posteriormente, o usuário muda de cargo e é removido da organização
Mona.
Quando o usuário acessar seu aplicativo, ele ainda poderá ver o código e a análise da organização Mona em sua conta de usuário?
Por isso é fundamental rastrear a origem dos dados que seu aplicativo está salvando. Se não, seu aplicativo é uma ameaça à proteção de dados das organizações, e há grande possibilidade de que seja banido se elas não puderem confiar que o aplicativo proteja corretamente os dados.
Verifique o acesso de um usuário ao seu aplicativo
Seu aplicativo OAuth pode ser acessado por usuários fora de sua organização ou empresa. Se você pretende que um aplicativo seja usado apenas por membros de sua organização ou empresa, verifique o status de associação do usuário quando ele entrar em seu aplicativo.
Para localizar a lista de organizações das quais um usuário é membro, você pode usar o ponto de extremidade "Listar organizações para o usuário autenticado". Em seguida, você pode validar essa lista em relação a uma lista de organizações aprovadas para seu aplicativo. Para saber mais, confira Pontos de extremidade de API REST para organizações.
Note
No GitHub.com, mesmo um OAuth app criado por um conta de usuário gerenciada ou por uma organização com usuários gerenciados pode ser acessado por usuários de fora da empresa.
Proteger as credenciais do aplicativo
Com um segredo do cliente, o aplicativo pode autorizar o usuário e gerar tokens de acesso do usuário. Os tokens podem ser usados para fazer solicitações de API em nome de um usuário.
Você precisa armazenar o segredo do cliente do aplicativo e todos os tokens gerados com segurança. O mecanismo de armazenamento depende da arquitetura de integrações e da plataforma em que ele é executado. Em geral, você deve usar um mecanismo de armazenamento destinado a armazenar dados confidenciais na plataforma que você está usando.
Segredos do cliente
Se o seu aplicativo for um site ou aplicativo Web, armazene o segredo do cliente em um cofre de chaves, como o Azure Key Vault ou como uma variável de ambiente criptografada ou um segredo em seu servidor.
Se o seu aplicativo for um cliente nativo, um aplicativo do lado do cliente ou for executado em um dispositivo de usuário (em vez de ser executado em seus servidores), você não poderá proteger o segredo do cliente. Tenha cuidado se você planeja acessar os serviços com base em tokens gerados pelo aplicativo, pois qualquer pessoa pode acessar o segredo do cliente para gerar um token.
Tokens de acesso do usuário
Se o seu aplicativo for um site ou aplicativo Web, você deverá criptografar os tokens no back-end e garantir que haja segurança em torno dos sistemas que podem acessar os tokens. Armazene os tokens de atualização em um local separado dos tokens de acesso ativos.
Se o seu aplicativo for um cliente nativo, um aplicativo do lado do cliente ou executado em um dispositivo de usuário (em vez de ser executado em seus servidores), talvez você não consiga proteger tokens, bem como um aplicativo executado em seus servidores. Você deve armazenar tokens por meio do mecanismo recomendado para a plataforma do aplicativo e ter em mente que o mecanismo de armazenamento pode não ser totalmente seguro.
Use o tipo de token apropriado
Os OAuth apps podem gerar tokens de acesso do usuário para fazer solicitações de API não autenticadas. O aplicativo nunca deve usar uma senha de personal access token ou GitHub para autenticação.
Criar um plano para lidar com violações de segurança
Você deve ter um plano em vigor para que possa lidar com quaisquer violações de segurança em tempo hábil.
Caso o segredo do cliente do aplicativo seja comprometido, você precisará gerar um novo segredo, atualizar o aplicativo para usá-lo e excluir o segredo antigo.
Caso esses tokens de acesso do usuário sejam comprometidos, você deverá revogá-los imediatamente. Para saber mais, confira Pontos de extremidade da API REST para autorizações de OAuth.
Realizar verificações de vulnerabilidade regulares
Você deve realizar verificações regulares de vulnerabilidade do aplicativo. Por exemplo, você pode configurar a verificação de código e a verificação de segredo no repositório que hospeda o código do aplicativo. Para obter mais informações, confira "Sobre a varredura de código" e "Sobre a verificação de segredo."
Escolher um ambiente apropriado
Se o aplicativo for executado em um servidor, verifique se o ambiente do servidor é seguro e se ele pode lidar com o volume de tráfego esperado para seu aplicativo.
Usar serviços de maneira segura
Se o aplicativo usar serviços de terceiros, isso deverá ocorrer de maneira segura:
- todos os serviços usados pelo aplicativo devem ter um logon exclusivo e uma senha.
- Os aplicativos não devem compartilhar contas de serviço como, por exemplo, e-mail ou serviços de banco de dados para gerenciar seu serviço de SaaS.
- Somente os funcionários com funções administrativas devem ter acesso de administrador à infraestrutura que hospeda o aplicativo.
Adicionar log e monitoramento
Considere adicionar funcionalidades de log e monitoramento no aplicativo. Um log de segurança pode incluir:
- Eventos de autenticação e autorização
- Alterações na configuração do serviço
- Leitura e gravação de objetos
- Alterações de permissão de usuário e grupo
- Elevação do papel para administrador
Os logs devem usar carimbos de data/hora consistentes para cada evento e registrar usuários, endereços IP ou nomes de host de todos os eventos registrados.
Habilitar a exclusão de dados
Se o aplicativo estiver disponível para outros usuários, ofereça aos usuários uma forma de excluir os dados. Os usuários não devem precisar enviar um email ou chamar uma pessoa de suporte para excluir os dados.