{"meta":{"title":"Práticas recomendadas para criar um aplicativo OAuth","intro":"Siga estas práticas recomendadas para melhorar a segurança e o desempenho de sua OAuth app.","product":"Aplicativos","breadcrumbs":[{"href":"/pt/apps","title":"Aplicativos"},{"href":"/pt/apps/oauth-apps","title":"Aplicativos OAuth"},{"href":"/pt/apps/oauth-apps/building-oauth-apps","title":"Criar aplicativos OAuth"},{"href":"/pt/apps/oauth-apps/building-oauth-apps/best-practices-for-creating-an-oauth-app","title":"Práticas recomendadas"}],"documentType":"article"},"body":"# Práticas recomendadas para criar um aplicativo OAuth\n\nSiga estas práticas recomendadas para melhorar a segurança e o desempenho de sua OAuth app.\n\n## Em vez disso, use um GitHub App\n\nSe possível, considere usar um GitHub App em vez de um OAuth app. Em geral, GitHub Apps são preferenciais em vez de OAuth apps.\nGitHub Apps use permissões refinadas, dê ao usuário mais controle sobre quais repositórios o aplicativo pode acessar e use tokens de curta duração. Essas propriedades podem aprimorar a segurança do aplicativo, limitando o dano possível decorrente do vazamento das credenciais.\n\nSemelhante a OAuth apps, GitHub Apps ainda pode usar o OAuth 2.0 e gerar um tipo de token OAuth (chamado de token de acesso) e executar ações em nome de um usuário. No entanto, GitHub Apps também pode agir independentemente de um usuário.\n\nPara obter mais informações sobre GitHub Apps, confira [Sobre a criação de aplicativos GitHub](/pt/apps/creating-github-apps/about-creating-github-apps/about-creating-github-apps).\n\nPara obter mais informações sobre como migrar um existente OAuth app para um GitHub App, consulte [Migrando aplicativos OAuth para aplicativos GitHub](/pt/apps/creating-github-apps/about-creating-github-apps/migrating-oauth-apps-to-github-apps).\n\n## Usar escopos mínimos\n\nVocê 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](/pt/apps/oauth-apps/building-oauth-apps/authorizing-oauth-apps).\n\n## Autorizar de forma completa e duradoura\n\nDepois 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.\n\n### Use o `id` durável e exclusivo para armazenar o usuário\n\nQuando 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.\n\nPara 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 [Endpoints de API REST para usuários](/pt/rest/users/users#get-a-user).\n\nSe 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.\n\n*Nunca* use identificadores que possam mudar ao longo do tempo, incluindo identificadores de usuário, slugs de organização ou endereços de email.\n\n### Validar o acesso da organização para cada nova autenticação\n\nAo conectar um usuário, você deve acompanhar para quais organizações o token do usuário está autorizado. Isso pode mudar ao longo do tempo depois que os usuários Entrar como são removidos das organizações. 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 de API REST do `GET /user/installations` para verificar a quais organizações o token de acesso de um usuário tem acesso. Se o usuário não estiver autorizado a acessar uma organização, você deverá impedir o acesso aos dados pertencentes à organização dentro do seu aplicativo até que ele faça SSO SAML ou ingresse novamente na organização. Para saber mais, confira [Pontos de extremidade da API REST para GitHub App instalações](/pt/rest/apps/installations#list-app-installations-accessible-to-the-user-access-token).\n\n### Armazenar dados do usuário com contextos organizacionais e corporativos\n\nAlé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.\n\nPor exemplo:\n\n1. 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 do `Mona`.\n2. O usuário extrai um monte de código de um repositório em `Mona` e salva em seu aplicativo para análise.\n3. Posteriormente, o usuário muda de cargo e é removido da organização `Mona`.\n\nQuando 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?\n\nPor 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.\n\n### Verifique o acesso de um usuário ao seu aplicativo\n\naplicativo OAuth poderá 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.\n\nPara encontrar a lista de organizações das quais um usuário é membro, você pode usar o endpoint \"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](/pt/rest/orgs/orgs#list-organizations-for-the-authenticated-user).\n\n## Proteger as credenciais do aplicativo\n\nCom um segredo de cliente e o código de autorização de um usuário, seu aplicativo pode autenticar um usuário e gerar tokens de acesso. Os tokens podem ser usados para fazer solicitações de API em nome de um usuário.\n\nVocê deve armazenar o segredo do cliente do aplicativo e todos os tokens gerados com segurança, se possível. O mecanismo de armazenamento e sua segurança relativa dependem da arquitetura de integrações e da plataforma em que ela é executada. Em geral, você deve usar um mecanismo de armazenamento destinado a armazenar dados confidenciais na plataforma que você está usando.\n\n### Segredos do cliente\n\nOs segredos do cliente são necessários para gerar tokens de acesso para seu aplicativo, a menos que seu aplicativo use o fluxo do dispositivo. Para saber mais, confira [Autorizar aplicativos OAuth](/pt/apps/oauth-apps/building-oauth-apps/authorizing-oauth-apps#device-flow).\n\nSe o aplicativo for um cliente confidencial, o que significa que ele pode manter o segredo do cliente seguro com segurança, considere armazenar o segredo do cliente em um cofre de chaves, como [Azure Key Vault](https://azure.microsoft.com/products/key-vault) ou como uma variável de ambiente criptografada ou segredo em seu servidor.\n\nSe seu aplicativo for um cliente público (um aplicativo nativo executado no dispositivo do usuário, utilitário da CLI ou aplicativo Web de página única), você não poderá proteger o segredo do cliente. Você precisará enviar o segredo do cliente no código do aplicativo e deve usar o PKCE para proteger melhor o fluxo de autenticação. Tenha cuidado se você planeja restringir o acesso a seus próprios serviços com base nos tokens gerados por seu aplicativo, pois clientes públicos são fáceis de falsificar – qualquer pessoa pode reutilizar a ID do cliente para entrar.\n\n#### Não habilite o fluxo do dispositivo sem motivo\n\nÉ preferível usar o código de autorização com PKCE em vez do fluxo do dispositivo se você estiver preocupado em usar o segredo do cliente em um cliente público. O fluxo do dispositivo não requer URIs de redirecionamento, o que significa que um invasor pode usar o fluxo do dispositivo para representar remotamente seu aplicativo como parte de um ataque de phishing. Por esse motivo, não habilite o fluxo de dispositivo para o aplicativo, a menos que você esteja usando o aplicativo em um ambiente restrito (CLIs, dispositivos IoT ou sistemas sem cabeçalho).\n\n### Tokens de acesso\n\nSe 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.\n\nSe 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.\n\n## Use o tipo de token apropriado\n\nOAuth apps pode gerar tokens de acesso para fazer solicitações de API autenticadas. Seu aplicativo nunca deve usar uma personal access token ou GitHub senha para autenticar.\n\n## Usar tokens de acesso com expiração\n\nPara garantir a rotação regular de tokens e reduzir o impacto de um token comprometido, você deve configurar seu OAuth app para usar tokens de acesso que expiram. Quando seu aplicativo usa tokens de acesso que expiram, você receberá um token de atualização ao gerar um token de acesso. O token de acesso expira após oito horas e o token de atualização expira após seis meses. Você pode usar o token de atualização para gerar um novo token de acesso e um novo token de atualização. Para saber mais, confira [Autorizar aplicativos OAuth](/pt/apps/oauth-apps/building-oauth-apps/authorizing-oauth-apps#expiring-access-tokens).\n\nPara testar e implementar gradualmente o suporte a tokens com expiração, você pode optar por receber tokens com expiração em um login, solicitando o escopo `offline_access` além dos outros escopos. Se o aplicativo der suporte a ambos GitHub Enterprise Server e GitHub.com, esteja preparado para que o `offline_access` escopo não tenha efeito, pois a GitHub Enterprise Server instância ainda pode não dar suporte a tokens expirando. Verifique a presença do `expires_in` campo na resposta do token para entender se seu aplicativo recebeu um token expirando.\n\n## Habilitar correspondência com curingas para URLs de retorno de chamada somente quando necessário\n\n> \\[!WARNING]\n> Habilitar a correspondência com curinga pode expor seu aplicativo a riscos de segurança, pois permite que um invasor envie códigos de autorização para qualquer subdomínio ou subdiretório na URL de retorno de chamada. Só habilite a correspondência de curinga se você precisar absolutamente dela e tiver certeza absoluta de que controlará todos os subdomínios e caminhos possíveis da URL de retorno de chamada. Para obter mais informações, consulte a [melhor prática atual de segurança do OAuth 2.0](https://www.rfc-editor.org/info/rfc9700/#section-4.1.1-11).\n\n## Criar um plano para lidar com violações de segurança\n\nVocê deve ter um plano em vigor para que possa lidar com quaisquer violações de segurança em tempo hábil.\n\nCaso 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.\n\nCaso os tokens de acesso sejam comprometidos, você deverá revogar imediatamente esses tokens. Para saber mais, confira [Pontos de extremidade da API REST para autorizações de OAuth](/pt/rest/apps/oauth-applications#delete-an-app-token).\n\n## Realizar verificações de vulnerabilidade regulares\n\nVocê 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 saber mais, confira [Análise de código](/pt/code-security/concepts/code-scanning/code-scanning) e [Escaneamento de segredos](/pt/code-security/concepts/secret-security/secret-scanning).\n\n## Escolher um ambiente apropriado\n\nSe 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.\n\n## Usar serviços de maneira segura\n\nSe o aplicativo usar serviços de terceiros, isso deverá ocorrer de maneira segura:\n\n* todos os serviços usados pelo aplicativo devem ter um logon exclusivo e uma senha.\n* 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.\n* Somente os funcionários com funções administrativas devem ter acesso de administrador à infraestrutura que hospeda o aplicativo.\n\n## Adicionar registro de atividades e monitoramento\n\nConsidere adicionar funcionalidades de log e monitoramento no aplicativo. Um log de segurança pode incluir:\n\n* Eventos de autenticação e autorização\n* Alterações na configuração do serviço\n* Leitura e gravação de objetos\n* Alterações de permissão de usuário e grupo\n* Elevação do papel para administrador\n\nOs 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.\n\n## Habilitar a exclusão de dados\n\nSe 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.\n\n## Leitura adicional\n\n* [Práticas recomendadas de segurança para aplicativos no GitHub Marketplace](/pt/apps/github-marketplace/creating-apps-for-github-marketplace/security-best-practices-for-apps-on-github-marketplace)\n* [Práticas recomendadas de experiência do cliente para aplicativos](/pt/apps/github-marketplace/creating-apps-for-github-marketplace/customer-experience-best-practices-for-apps)"}