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:
- Os usuários são redirecionados para solicitar sua identidade do GitHub
- Os usuários são redirecionados de volta para o seu site pelo GitHub
- 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
Nome | Tipo | Descrição |
---|---|---|
client_id | string | Obrigatório. O ID do cliente que você recebeu do GitHub quando você registrados. |
redirect_uri | string | A 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. |
login | string | Sugere uma conta específica para iniciar a sessão e autorizar o aplicativo. |
escopo | string | Uma 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 do usuárioe do repositório`. |
estado | string | Uma string aleatória indescritível. É usado para proteger contra ataques de falsificação de pedidos entre sites. |
allow_signup | string | Independentemente 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
Nome | Tipo | Descrição |
---|---|---|
client_id | string | Obrigatório. O ID do cliente que você recebeu do GitHub Enterprise para o seu aplicativo GitHub. |
client_secret | string | Obrigatório. O segredo do cliente que recebeu do GitHub Enterprise para o seu aplicativo GitHub. |
código | string | Obrigatório. O código que você recebeu como resposta ao Passo 1. |
redirect_uri | string | A URL do seu aplicativo para onde os usuários são enviados após a autorização. |
estado | string | A 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
:
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. "