Ao registrar uma GitHub App, você pode especificar uma URL de retorno de chamada. Quando você usa o fluxo do aplicativo da Web para gerar um token de acesso de usuário a fim de agir em nome de um usuário, os usuários serão redirecionados para a URL de callback depois de autorizar o GitHub App.
Você pode especificar até 10 URLs de retorno de chamada. Se você especificar várias URLs de retorno de chamada, deverá usar o parâmetro redirect_uri ao solicitar que o usuário autorize sua GitHub App, para indicar para qual URL de retorno de chamada o usuário deve ser redirecionado. Se você não especificar um redirect_uri, a primeira URL de callback será usada. Para obter mais informações sobre como usar o parâmetro redirect_uri, confira Gerando um token de acesso do usuário para um aplicativo GitHub.
A URL de retorno de chamada é diferente da URL de configuração. Os usuários são redirecionados para a URL de instalação depois que instalam um GitHub App. Os usuários são redirecionados para a URL de callback quando autorizam um GitHub App por meio do fluxo de aplicativo da Web. Para saber mais, confira Sobre a URL de instalação.
Para obter mais informações sobre como gerar tokens de acesso de usuário, confira Gerando um token de acesso do usuário para um aplicativo GitHub. Para obter mais informações sobre como registrar um GitHub App, consulte Registrando um aplicativo GitHub. Para obter mais informações sobre como modificar um GitHub App registro, consulte Modificando um registro de aplicativo GitHub.
Correspondência curinga para URLs de retorno de chamada
Se necessário, você pode habilitar a correspondência curinga para uma URL de retorno de chamada. Quando a correspondência com caracteres curinga estiver habilitada, o host da URL de redirecionamento (excluindo subdomínios) e a porta devem corresponder exatamente aos da URL de callback, e o caminho da URL de redirecionamento deve fazer referência a um subdiretório da URL de callback. Isso significa que qualquer subdomínio ou subdiretório da URL de callback corresponderá e será permitido como URL de callback. Por exemplo, se a correspondência com caractere curinga estiver habilitada para a URL https://example.com/path de retorno de chamada:
CALLBACK: https://example.com/path
MATCH: https://example.com/path
MATCH: https://example.com/path/subdir/other
MATCH: https://oauth.example.com/path
MATCH: https://oauth.example.com/path/subdir/other
FAIL: https://example.com/bar
FAIL: https://example.com/
FAIL: https://example.com:8080/path
FAIL: https://oauth.example.com:8080/path
FAIL: https://example.org
Quando a correspondência por curinga estiver desabilitada, a URL de redirecionamento deve corresponder exatamente à URL de callback. Você pode ativar ou desativar a correspondência com caractere curinga para cada URL de callback nas configurações do seu aplicativo.
Aviso
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.
Os aplicativos que tinham uma única URL de callback habilitada antes de 3 de agosto de 2026 têm a correspondência por caractere curinga ativada para essa URL de callback. Isso preserva o comportamento de redirecionamento que existia antes de a correspondência com curingas passar a ser uma configuração ajustável, e essa é a razão pela qual todos os OAuth apps e alguns GitHub Apps criados antes dessa data têm a correspondência com curingas habilitada. Se o aplicativo não precisar de correspondência com curinga, recomendamos desativar esse recurso.