Publicamos atualizações frequentes em nossa documentação, e a tradução desta página ainda pode estar em andamento. Para obter as informações mais recentes, acesse a documentação em inglês. Se houver problemas com a tradução desta página, entre em contato conosco.

Esta versão do GitHub Enterprise será descontinuada em Esta versão do GitHub Enterprise foi descontinuada em 2020-08-20. Nenhum lançamento de patch será feito, mesmo para questões críticas de segurança. Para obter melhor desempenho, melhorar a segurança e novos recursos, upgrade to the latest version of GitHub Enterprise. Para ajuda com a atualização, contact GitHub Enterprise support.

Versão do artigo: Enterprise Server 2.18

Autorizar aplicativos OAuth

You can enable other users to authorize your OAuth App.

Neste artigo

GitHub Enterprise's OAuth implementation supports the standard authorization code grant type.

If you want to skip authorizing your app in the standard way, such as when testing your app, you can use the non-web application flow.

For standard apps that run in the browser, use the web application flow to obtain an authorization code and exchange it for a token. (O tipo implícito de concessão não é compatível)

Fluxo do aplicativo web

Observação: Se você está criando um aplicativo GitHub, você ainda pode usar o fluxo do aplicativo web OAuth, mas a configuração tem algumas diferenças importantes. Consulte "Identificando e autorizando usuários para aplicativos GitHub" para obter mais informações.

The web application flow to authorize users for your app is:

  1. Os usuários são redirecionados para solicitar sua identidade do GitHub
  2. Os usuários são redirecionados de volta para o seu site pelo GitHub
  3. Seu aplicativo acessa a API com o token de acesso do usuário

1. Solicitar identidade do GitHub de um usuário

GET http(s)://[hostname]/login/oauth/authorize

Quando seu aplicativo GitHub especifica um parâmetro do login, ele solicita aos usuários com uma conta específica que podem usar para iniciar sessão e autorizar seu aplicativo.

Parâmetros
NomeTipoDescrição
client_idstringObrigatório. O ID do cliente que você recebeu do GitHub quando você registrados.
redirect_uristringA URL no seu aplicativo para o qual os usuários serão enviados após a autorização. Veja os detalhes abaixo sobre redirecionamento das urls.
loginstringSugere uma conta específica para iniciar a sessão e autorizar o aplicativo.
escopostringUma lista de escopos delimitada por espaço. Caso não seja fornecido, o escopo-padrão será uma lista vazia para usuários que não autorizaram nenhum escopo para o aplicativo. Para usuários que têm escopos autorizados para o aplicativo, a página de autorização OAuth com a lista de escopos não será exibida para o usuário. Em vez disso, esta etapa do fluxo será concluída automaticamente com o conjunto de escopos que o usuário autorizou para o aplicativo. Por exemplo, se um usuário já executou o fluxo web duas vezes e autorizou um token com escopo do usuário e outro token com o escopo do repositório, um terceiro fluxo web que não fornece um escopo `receberá um token com os escopos dousuárioe dorepositório`.
estadostringUma string aleatória indescritível. É usado para proteger contra ataques de falsificação de pedidos entre sites.
allow_signupstringIndependentemente de os usuários serem autenticados, eles receberão uma opção para inscrever-se no GitHub durante o fluxo do OAuth. O padrão é verdadeiro. Use falso quando uma política proibir inscrições.

2. Os usuários são redirecionados de volta para o seu site pelo GitHub

Se o usuário aceitar a sua solicitação, o GitHub Enterprise redireciona de volta para seu site com código temporário em um parâmetro de código, bem como o estado que você forneceu na etapa anterior em um parâmetro de estado. O código temporário irá expirar após 10 minutos. Se os estados não corresponderem, significa que uma terceira criou a solicitação, e você deverá abortar o processo.

Troque este código por um token de acesso:

POST http(s)://[hostname]/login/oauth/access_token
Parâmetros
NomeTipoDescrição
client_idstringObrigatório. O ID do cliente que você recebeu do GitHub Enterprise para o seu aplicativo GitHub.
client_secretstringObrigatório. O segredo do cliente que recebeu do GitHub Enterprise para o seu aplicativo GitHub.
códigostringObrigatório. O código que você recebeu como resposta ao Passo 1.
redirect_uristringA URL do seu aplicativo para onde os usuários são enviados após a autorização.
estadostringA string aleatória inexplicável que você forneceu na etapa 1.
Resposta

Por padrão, a resposta assume o seguinte formato:

access_token=e72e16c7e42f292c6912e7710c838347ae178b4a&token_type=bearer

Você também pode receber o conteúdo em diferentes formatos, dependendo do cabeçalho Aceitar:

Accept: application/json
{"access_token":"e72e16c7e42f292c6912e7710c838347ae178b4a", "scope":"repo,gist", "token_type":"bearer"}

Accept: application/xml
<OAuth>
  <token_type>bearer</token_type>
  <scope>repo,gist</scope>
  <access_token>e72e16c7e42f292c6912e7710c838347ae178b4a</access_token>
</OAuth>

3. Use o token de acesso para acessar a API

O token de acesso permite que você faça solicitações para a API em nome de um usuário.

Autorização: token OUTH-TOKEN
GET http(s)://[hostname]/api/v3/user

Por exemplo, no cURL você pode definir o cabeçalho de autorização da seguinte forma:

curl -H "Authorization: token OAUTH-TOKEN" http(s)://[hostname]/api/v3/user

Fluxo do aplicativo que não são da web

A autenticação que não é da web está disponível para situações limitadas como testes. Se necessário, você pode usar a autenticação básica para criar um token de acesso usando a sua página pessoal de configurações de tokens de acesso. Essa técnica permite ao usuário revogar o acesso a qualquer momento.

Observação: Quando usar o fluxo do aplicativo que não é web para criar um token do OAuth2, certifique-se de entender como trabalhar com a autenticação de dois fatores se você ou seus usuários tiverem a autenticação de dois fatores habilitada.

URLs de redirecionamento

O parâmetro redirect_uri é opcional. Se ignorado, o GitHub redirecionará os usuários para a URL de retorno de chamada definida nas configurações do aplicativo OAuth. Se fornecido, o host e porta do URL de redirecionamento deve exatamente corresponder à URL de retorno de chamada. O caminho da URL de redirecionamento deve fazer referência uma subpasta da URL de retorno de chamada.

RETORNO DE CHAMADA: http://example.com/path

GOOD: http://example.com/path
GOOD: http://example.com/path/subdir/other
BAD:  http://example.com/bar
BAD:  http://example.com/
BAD:  http://example.com:8080/path
BAD:  http://oauth.example.com:8080/path
BAD:  http://example.org

URLs de redirecionamento do Localhost

O parâmetro opcional redirect_uri também pode ser usado para URLs do localhhost. Se o aplicativo especificar uma URL do localhost e uma porta, após a autorização, os usuários do aplicativo serão redirecionados para a URL e porta fornecidas. O redirect_uri não precisa corresponder à porta especificada na URL de retorno de chamada do aplicativo.

Para a URL de retorno de chamada http://localhost/path, você poderá usar este redirect_uri:

http://localhost:1234/path

Criar vários tokens para aplicativos OAuth

Você pode criar vários tokens para uma combinação de usuário/aplicativo/escopo para criar tokens para casos de uso específicos.

Isso é útil se o seu aplicativo OAuth for compatível com um fluxo de trabalho que usa o GitHub para iniciar sessão e exigir apenas informações básicas do usuário. Outro fluxo de trabalho pode exigir acesso aos repositórios privados de um usuário. Ao usar vários tokens, o seu aplicativo OAuth pode realizar o fluxo web para cada caso, solicitando apenas os escopos necessários. Se um usuário usar apenas seu aplicativo para iniciar a sessão, ele nunca será obrigado a conceder acesso do aplicativo OAuth aos seus repositórios privados.

Há um limite para o número de tokens emitidos por combinação de usuário/aplicativo/escopo. Se seu aplicativo solicitar tokens suficientes para ultrapassar um dos limites, os tokens antigos com o mesmo escopo sendo solicitado irão parar de funcionar.

Warning: Revogar todas as permissões de um aplicativo OAuth exclui quaisquer chaves SSH geradas pelo aplicativo em nome do usuário, incluindo deploy keys.

Direcionar os usuários para revisar seus acessos

Você pode vincular informações sobre a autorização de um aplicativo OAuth para que os usuários possam revisar e revogar as autorizações do seu aplicativo.

Para criar esse vínculo, você precisará do client_id dos aplicativos OAuth, que você recebeu do GitHub quando fez o cadastro no aplicativo.

http(s)://[hostname]/settings/connections/applications/:client_id

Dica: Para saber mais sobre os recursos que seu aplicativo OAuth pode acessar para um usuário, consulte "Descobrindo recursos para um usuário. "

Solução de Problemas

Pergunte a uma pessoa

Não consegue encontrar o que procura?

Entrar em contato