Autorisation des applications OAuth

GitHubL’implémentation OAuth prend en charge le type d’octroi de code d’autorisation standard et l’octroi d’autorisation d’appareil OAuth 2.0 pour les applications qui n’ont pas accès à un navigateur web.

Si vous souhaitez ignorer l’autorisation de votre application de manière standard, par exemple durant le test de votre application, vous pouvez utiliser le flux d’application non web.

Pour autoriser votre OAuth appapplication, considérez le flux d’autorisation le mieux adapté à votre application.

• flux d’application Web : permet d’autoriser les utilisateurs des applications OAuth apps standard qui s’exécutent dans le navigateur. (Le type d’autorisation implicite n’est pas pris en charge.)
• flux d’appareil : utilisé pour les applications sans périphérique de contrôle, par exemple les outils CLI.

Jetons d’accès arrivant à expiration

Pour appliquer une rotation régulière des jetons et réduire l’impact d’un jeton compromis, vous pouvez configurer votre OAuth app pour obtenir des jetons d’accès qui expirent. Lorsque votre application utilise des jetons d’accès qui expirent, vous recevrez également un jeton d’actualisation avec votre jeton d’accès. Le flux d’application web et le flux d’appareil prennent en charge les jetons expirables.

Le jeton d’accès expire après huit heures et le jeton d’actualisation expire après six mois sans utilisation. Vous pouvez utiliser le jeton d’actualisation pour générer un nouveau jeton d’accès et un nouveau jeton d’actualisation. Pour plus d’informations, consultez Actualisation d’un jeton d’accès avec un jeton d’actualisation.

Activation des jetons à expiration à l’exécution

Pour tester et déployer progressivement la prise en charge des jetons arrivant à expiration, vous pouvez choisir de recevoir un jeton d’expiration et un jeton d’actualisation pour une connexion individuelle en demandant l’étendue offline_access en plus de vos autres étendues. Lorsque vous demandez l’étendue offline_access , vous recevrez un jeton d’accès arrivant à expiration et un jeton d’actualisation, même si votre application n’est pas configurée pour utiliser des jetons arrivant à expiration.

Si votre application prend en charge à la fois GitHub Enterprise Server et GitHub.com, vous devez vous attendre à ce que la portée offline_access n’ait aucun effet, car l’instance GitHub Enterprise Server ne prend peut-être pas encore en charge l’expiration des jetons. Dans ce cas, vous recevrez un jeton non expiré et aucun jeton d’actualisation. Par conséquent, votre application ne doit pas supposer qu’un jeton d’actualisation est toujours retourné.

Exiger des jetons arrivant à expiration pour votre application

Une fois que vous avez mis à jour votre application pour utiliser des jetons d’actualisation pour gérer l’expiration des jetons, vous pouvez forcer l’expiration du jeton pour votre application globalement. Cela fera que tous les nouveaux jetons seront émis avec une date d’expiration et un jeton d’actualisation. L’activation de cette fonctionnalité n’entraîne pas l’expiration des jetons existants. Elles continueront d’être durables. Si vous souhaitez passer à des jetons expirants, demandez à l’utilisateur de se reconnecter. Pour configurer ce paramètre pour votre application, consultez Activation de fonctionnalités facultatives pour les applications OAuth.

Flux d’application web

Le flux d’application web permettant d’autoriser les utilisateurs pour votre application est le suivant :

1. Les utilisateurs sont redirigés pour demander leur identité GitHub
2. Les utilisateurs sont redirigés vers votre site par GitHub
3. Votre application accède à l’API avec le jeton d’accès de l’utilisateur

1. Demander l'identité GitHub d'un utilisateur

GET https://github.com/login/oauth/authorize

Ce point de terminaison accepte les paramètres d’entrée suivants.

Paramètre de requête.	Type	Requis ?	Description
client_id	string	Obligatoire	ID client que vous avez reçu de GitHub lors de .
redirect_uri	string	Fortement recommandé	URL de votre application où les utilisateurs sont redirigés après l’autorisation. Consultez les détails ci-dessous sur les URL de redirection.
login	string	Facultatif	Suggère un compte spécifique à utiliser pour la connexion et l’autorisation de l’application.
scope	string	Dépendant du contexte	Liste d’étendues délimitées par des espaces. En l’absence d’indication, la valeur par défaut de scope est une liste vide, si les utilisateurs n’ont autorisé aucune étendue pour l’application. Quand les utilisateurs disposent d’étendues d’autorisation pour l’application, ils ne voient pas s’afficher la page d’autorisation OAuth comportant la liste des étendues. À la place, cette étape du flux se complètera automatiquement avec l'ensemble des périmètres que l'utilisateur a autorisés pour l'application. Par exemple, si un utilisateur a déjà effectué le flux web à deux reprises et s’il a autorisé un jeton avec l’étendue user ainsi qu’un autre jeton avec l’étendue repo, un troisième flux web qui ne fournit pas de scope reçoit un jeton avec l’étendue user et l’étendue repo.
L’utilisation de l’étendue offline_access pour obtenir un jeton arrivant à expiration ne modifie pas le comportement de l’étendue . Elle n’est pas suivie comme une étendue classique comme repo ou user, et n’entraîne pas l’apparition d’invites supplémentaires si elle est utilisée.
state	string	Fortement recommandé	Chaîne aléatoire non modifiable. Elle est utilisée pour protéger contre les attaques de falsification de requête intersite.
code_challenge	string	Fortement recommandé	Utilisé pour sécuriser le flux d’authentification avec PKCE (Clé de preuve pour l’échange de code). Obligatoire si code_challenge_method est inclus. Doit être un hachage SHA-256 de 43 caractères d’une chaîne aléatoire générée par le client. Pour plus d’informations sur cette extension de sécurité, consultez la RFC PKCE.
code_challenge_method	string	Fortement recommandé	Utilisé pour sécuriser le flux d’authentification avec PKCE (Clé de preuve pour l’échange de code). Obligatoire si code_challenge est inclus. Doit être S256 - la méthode de challenge de code plain n'est pas supportée.
allow_signup	string	Facultatif	Si des utilisateurs non authentifiés se verront proposer une option de s'inscrire à GitHub pendant le processus OAuth. La valeur par défaut est true. Utilisez false quand une stratégie interdit les inscriptions.
prompt	string	Facultatif	Force l’affichage du sélecteur de compte lorsqu’il est défini sur select_account. Le sélecteur de compte s’affichera également si l’application a une URI de redirection non HTTP ou si l’utilisateur a plusieurs comptes connectés.

Les requêtes de pré-vérification CORS (OPTIONS) ne sont pas prises en charge pour l’instant.

2. Les utilisateurs sont redirigés vers votre site par GitHub

Si l’utilisateur accepte votre demande, GitHub redirige de nouveau vers votre site avec un code temporaire dans un paramètre de code, ainsi que l’état que vous avez fourni à l’étape précédente dans un paramètre state. Le code temporaire expire après 10 minutes. Si les états ne correspondent pas, un tiers créé la requête, et vous devez abandonner le processus.

Échangez ce code contre un jeton d’accès :

POST https://github.com/login/oauth/access_token

Ce point de terminaison accepte les paramètres d’entrée suivants.

Nom du paramètre	Type	Requis ?	Description
client_id	string	Obligatoire	L’ID client que vous avez reçu de GitHub pour votre OAuth app.
client_secret	string	Obligatoire	Le secret client que vous avez reçu de GitHub pour votre OAuth app.
code	string	Obligatoire	Code que vous avez reçu en réponse à l’étape 1.
redirect_uri	string	Fortement recommandé	URL de votre application où les utilisateurs sont redirigés après l’autorisation. Nous pouvons l’utiliser pour faire correspondre l’URI fourni à l’origine lorsque le code a été émis, afin d’empêcher les attaques contre votre service.
code_verifier	string	Fortement recommandé	Utilisé pour sécuriser le flux d’authentification avec PKCE (Clé de preuve pour l’échange de code). Obligatoire si code_challenge a été envoyé pendant l’autorisation de l’utilisateur. Doit être la valeur d’origine utilisée pour générer l' code_challenge dans la demande d’autorisation. Cela peut être stocké dans un cookie en même temps que le paramètre state ou dans une variable de session pendant l’authentification, en fonction de l’architecture de votre application.

Par défaut, la réponse prend la forme suivante :

access_token=gho_16C7e42F292c6912E7710c838347Ae178B4a
&scope=repo%2Cgist
&token_type=bearer

Vous pouvez également recevoir la réponse dans différents formats, si vous indiquez le format souhaité dans l’en-tête Accept. Par exemple Accept: application/json ou Accept: application/xml :

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

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

Si votre OAuth app utilise des jetons d’accès à expiration, ou si vous avez demandé la portée offline_access, la réponse inclut également un refresh_token, ainsi que les valeurs expires_in et refresh_token_expires_in qui indiquent quand chaque jeton expire (en secondes à partir du moment actuel). Pour plus d’informations, consultez Jetons d’accès arrivant à expiration.

Par défaut, la réponse prend la forme suivante :

access_token=gho_16C7e42F292c6912E7710c838347Ae178B4a
&expires_in=28800
&refresh_token=ghr_1B4a2e77838347a7E420ce178F2E7c6912E169246c34E1ccbF66C46812d16D5B1A9Dc86A1498
&refresh_token_expires_in=15897600
&scope=repo%2Cgist
&token_type=bearer

3. Utiliser le jeton d’accès pour accéder à l’API

Le jeton d’accès vous permet d’envoyer des requêtes à l’API au nom d’un utilisateur.

Authorization: Bearer OAUTH-TOKEN
GET https://api.github.com/user

Par exemple, avec curl, vous pouvez définir l’en-tête d’autorisation comme ceci :

curl -H "Authorization: Bearer OAUTH-TOKEN" https://api.github.com/user

Chaque fois que vous recevez un jeton d’accès, vous devez l’utiliser pour revalider l’identité de l’utilisateur. Un utilisateur peut changer le compte auquel il est connecté lorsque vous lui demandez d’autoriser votre application, et vous risquez de mélanger les données de l’utilisateur si vous ne validez pas l’identité de l’utilisateur après chaque connexion.

Flux d’appareil

Le flux d’appareil permet d’autoriser des utilisateurs pour une application sans interface graphique, comme un outil CLI ou le gestionnaire d’informations d’identification Git.

Avant de pouvoir utiliser le flux d’appareil pour autoriser et identifier des utilisateurs, vous devez d’abord l’activer dans les paramètres de votre application. Pour plus d’informations sur l’activation du flux d’appareil dans votre application, consultez Modification d’une inscription d’application GitHub pour GitHub Apps et Modification d’une application OAuth pour OAuth apps.

Vue d’ensemble du flux de dispositif

1. Votre application demande les codes de vérification d’appareil et d’utilisateur, puis obtient l’URL d’autorisation où l’utilisateur doit entrer le code de vérification d’utilisateur.
2. L’application invite l’utilisateur à entrer un code de vérification utilisateur à l’adresse https://github.com/login/device.
3. L’application interroge l’état de l’authentification de l’utilisateur. Une fois que l’utilisateur a autorisé l’appareil, l’application peut effectuer des appels d’API avec un nouveau jeton d’accès.

Étape 1 : l’application demande les codes de vérification de l’appareil et de l’utilisateur à partir de GitHub

POST https://github.com/login/device/code

Votre application doit demander un code de vérification d’utilisateur et une URL de vérification. Tous deux permettront à l’application d’inviter l’utilisateur à s’authentifier à l’étape suivante. Cette requête retourne également un code de vérification d’appareil que l’application doit utiliser pour recevoir un jeton d’accès et vérifier l’état de l’authentification de l’utilisateur.

Le point de terminaison accepte les paramètres d’entrée suivants.

Nom du paramètre	Type	Description
client_id	string
Obligatoire. L’ID client que vous avez reçu de GitHub pour votre application.
scope	string	Une liste délimitée par des espaces des périmètres auxquels votre application demande l'accès. Pour plus d’informations, consultez « Étendues des applications OAuth ».

Par défaut, la réponse prend la forme suivante :

device_code=3584d83530557fdd1f46af8289938c8ef79f9dc5
&expires_in=900
&interval=5
&user_code=WDJB-MJHT
&verification_uri=https%3A%2F%2Fgithub.com%2Flogin%2Fdevice

Nom du paramètre	Type	Description
device_code	string	Le code de vérification d’appareil comporte 40 caractères et sert à vérifier l’appareil.
user_code	string	Le code de vérification d’utilisateur s’affiche sur l’appareil pour permettre à l’utilisateur d’entrer ce code dans un navigateur. Il s’agit d’un code qui comporte 8 caractères avec un trait d’union au milieu.
verification_uri	string	L’URL de vérification où les utilisateurs doivent saisir le user_code : https://github.com/login/device.
expires_in	integer	Nombre de secondes avant l’expiration de device_code et user_code. La valeur par défaut est égale à 900 secondes (15 minutes).
interval	integer	Nombre minimal de secondes qui doivent s’écouler avant que vous ne puissiez effectuer une nouvelle demande de jeton d’accès (POST https://github.com/login/oauth/access_token) pour autoriser l’appareil. Par exemple, si l’intervalle est égal à 5, vous ne pouvez pas effectuer de nouvelle requête avant 5 secondes. Si vous effectuez plusieurs requêtes en 5 secondes, vous atteignez la limite de débit et recevez une erreur slow_down.

Vous pouvez également recevoir la réponse dans différents formats, si vous indiquez le format souhaité dans l’en-tête Accept. Par exemple Accept: application/json ou Accept: application/xml :

Accept: application/json
{
  "device_code": "3584d83530557fdd1f46af8289938c8ef79f9dc5",
  "user_code": "WDJB-MJHT",
  "verification_uri": "https://github.com/login/device",
  "expires_in": 900,
  "interval": 5
}

Accept: application/xml
<OAuth>
  <device_code>3584d83530557fdd1f46af8289938c8ef79f9dc5</device_code>
  <user_code>WDJB-MJHT</user_code>
  <verification_uri>https://github.com/login/device</verification_uri>
  <expires_in>900</expires_in>
  <interval>5</interval>
</OAuth>

Étape 2 : Inviter l’utilisateur à entrer le code utilisateur dans un navigateur

Votre appareil affiche le code de vérification de l’utilisateur et invite l’utilisateur à entrer le code à l’adresse https://github.com/login/device.

Étape 3 : l’application interroge GitHub pour vérifier si l’utilisateur a autorisé l’appareil

POST https://github.com/login/oauth/access_token

Votre application effectue des demandes d’autorisation d’appareil qui interrogent POST https://github.com/login/oauth/access_token, jusqu’à ce que les codes de vérification d’appareil et d’utilisateur expirent, ou jusqu’à ce que l’utilisateur parvienne à autoriser l’application avec un code utilisateur valide. L’application doit utiliser l’interrogation minimale interval récupérée à l’étape 1 pour éviter les erreurs de limite de débit. Pour plus d’informations, consultez « Limites de débit pour le flux d’appareil ».

L’utilisateur doit entrer un code valide dans un délai de 15 minutes (ou 900 secondes). Après 15 minutes, vous devez demander un nouveau code d’autorisation d’appareil avec POST https://github.com/login/device/code.

Une fois que l’utilisateur a effectué l’autorisation, l’application reçoit un jeton d’accès qui permet d’envoyer des requêtes à l’API au nom d’un utilisateur.

Le point de terminaison accepte les paramètres d’entrée suivants.

Nom du paramètre	Type	Description
client_id	string
Obligatoire. L’ID client que vous avez reçu de GitHub pour votre OAuth app.
device_code	string
Obligatoire. Le device_code reçu à partir de la requête POST https://github.com/login/device/code.
grant_type	string
Obligatoire. Le type d’octroi doit être urn:ietf:params:oauth:grant-type:device_code.

Par défaut, la réponse prend la forme suivante :

access_token=gho_16C7e42F292c6912E7710c838347Ae178B4a
&token_type=bearer
&scope=repo%2Cgist

Vous pouvez également recevoir la réponse dans différents formats, si vous indiquez le format souhaité dans l’en-tête Accept. Par exemple Accept: application/json ou Accept: application/xml :

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

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

Si OAuth app vous utilisez des jetons d’accès qui expirent, ou si vous avez demandé la portée offline_access, la réponse inclut également un refresh_token, ainsi que les valeurs expires_in et refresh_token_expires_in qui indiquent quand chaque jeton expire. Pour plus d’informations, consultez Jetons d’accès arrivant à expiration.

access_token=gho_16C7e42F292c6912E7710c838347Ae178B4a
&expires_in=28800
&refresh_token=ghr_1B4a2e77838347a7E420ce178F2E7c6912E169246c34E1ccbF66C46812d16D5B1A9Dc86A1498
&refresh_token_expires_in=15897600
&token_type=bearer
&scope=repo%2Cgist

Restrictions de vitesse pour le flux de périphérique

Quand un utilisateur envoie le code de vérification dans le navigateur, le débit est limité à 50 envois par heure et par application.

Si vous effectuez plusieurs demandes de jeton d’accès (POST https://github.com/login/oauth/access_token) sans respecter le délai d’exécution minimal nécessaire entre les demandes (ou interval), vous atteignez la limite de débit et recevez une réponse d’erreur slow_down. La réponse d’erreur slow_down ajoute 5 secondes au dernier interval. Pour plus d’informations, consultez les codes d'erreur du flux de l’appareil.

Codes d’erreur du flux de l'appareil

Code d'erreur	Description
authorization_pending	Cette erreur se produit quand la demande d’autorisation est en attente et que l’utilisateur n’a pas encore entré le code utilisateur. L’application doit continuer à interroger la requête POST https://github.com/login/oauth/access_token sans dépasser la valeur de interval, ce qui nécessite un nombre minimal de secondes entre chaque requête.
slow_down	Quand vous recevez l’erreur slow_down, 5 secondes supplémentaires sont ajoutées au interval ou au délai d’exécution minimal nécessaire entre vos requêtes à l’aide de POST https://github.com/login/oauth/access_token. Par exemple, si l’intervalle de démarrage nécessite au moins 5 secondes entre les requêtes et si vous obtenez une réponse d’erreur slow_down, vous devez attendre au moins 10 secondes avant d’effectuer une nouvelle requête pour un jeton d’accès OAuth. La réponse d’erreur inclut le nouveau interval à utiliser.
expired_token	Si le code d’appareil a expiré, l’erreur token_expired s’affiche. Vous devez effectuer une nouvelle requête pour l’obtention d’un code d’appareil.
unsupported_grant_type	Le type d’autorisation doit être urn:ietf:params:oauth:grant-type:device_code et doit être inclus en tant que paramètre d’entrée quand vous interrogez la demande de jeton OAuth POST https://github.com/login/oauth/access_token.
incorrect_client_credentials	Pour le flux d’appareil, vous devez passer l’ID client de votre application, que vous trouverez dans la page des paramètres de l’application. Le client_secret n’est pas nécessaire pour le flux de l'appareil.
incorrect_device_code	Le device_code fourni n’est pas valide.
access_denied	Lorsqu’un utilisateur clique sur Annuler pendant le processus d’autorisation, vous recevez une erreur access_denied et l’utilisateur ne peut plus utiliser le code de vérification.
device_flow_disabled	Le flux d’appareil n’a pas été activé dans les paramètres de l’application. Pour plus d’informations, consultez « Flux d’appareils ».

Pour plus d’informations, consultez l’« Octroi d’autorisation d’appareil OAuth 2.0 ».

Actualisation d’un jeton d’accès avec un jeton d’actualisation

Si vous OAuth app utilisez des jetons d’accès arrivant à expiration, vous pouvez utiliser le jeton d’actualisation pour générer un nouveau jeton d’accès et un nouveau jeton d’actualisation. Une fois que vous utilisez un jeton d’actualisation, ce jeton d’actualisation et l’ancien jeton d’accès ne fonctionneront plus. Pour plus d’informations sur les jetons arrivant à expiration, consultez Jetons d’accès arrivant à expiration.

Si votre jeton d’actualisation expire avant de l’utiliser, vous devez envoyer à nouveau l’utilisateur via le flux d’application web ou le flux d’appareil pour obtenir une nouvelle paire de jetons.

Pour actualiser un jeton d’accès, effectuez une requête POST vers l’URL suivante, avec les paramètres d’entrée ci-dessous.

POST https://github.com/login/oauth/access_token

Nom du paramètre	Type	Requis ?	Description
client_id	string	Obligatoire	L’ID client que vous avez reçu de GitHub pour votre OAuth app.
client_secret	string	Obligatoire, sauf si le jeton a été généré à l’aide du flux d’appareil	Le secret client que vous avez reçu de GitHub pour votre OAuth app.
grant_type	string	Obligatoire	La valeur doit être refresh_token.
refresh_token	string	Obligatoire	Jeton d’actualisation reçu lorsque vous avez généré un jeton d’accès.

Par défaut, la réponse prend la forme suivante :

access_token=gho_16C7e42F292c6912E7710c838347Ae178B4a
&expires_in=28800
&refresh_token=ghr_1B4a2e77838347a7E420ce178F2E7c6912E169246c34E1ccbF66C46812d16D5B1A9Dc86A1498
&refresh_token_expires_in=15897600
&scope=repo%2Cgist
&token_type=bearer

Les étendues du nouveau jeton d’accès correspondent aux étendues du jeton précédent. Vous ne pouvez pas fournir un scope paramètre pendant l’actualisation du jeton afin de modifier l’accès du jeton résultant.

Si le jeton d’actualisation que vous avez spécifié n’est pas valide ou a expiré, vous recevrez une erreur bad_refresh_token. Pour résoudre cette erreur, envoyez à nouveau l’utilisateur via le flux d’application web ou le flux d’appareil pour obtenir un nouveau jeton d’accès et un jeton d’actualisation.

Flux d’application non-web

L’authentification non-web est disponible pour des situations limitées, par exemple les tests. Si nécessaire, vous pouvez utiliser Basic Authentication pour créer un personal access token à l’aide de la page des paramètres de votre personal access token. Cette technique permet à l’utilisateur de révoquer l’accès à tout moment.

URL de redirection

Le paramètre redirect_uri est facultatif. S’il est omis, GitHub redirigera les utilisateurs vers la première URL de rappel configurée dans le OAuth app paramètres.

Si nécessaire, vous pouvez activer la correspondance de caractères génériques pour une URL de rappel. Lorsque la correspondance de caractères génériques est activée, l’hôte de l’URL de redirection (à l’exclusion des sous-domaines) et le port doivent correspondre exactement à l’URL de rappel, et le chemin d’accès de l’URL de redirection doit référencer un sous-répertoire de l’URL de rappel. Cela signifie que tout sous-domaine ou sous-répertoire de l’URL de rappel correspond et est autorisé en tant qu’URL de rappel. Par exemple, si la prise en charge des caractères génériques est activée pour l’URL de rappel https://example.com/path :

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

Lorsque la correspondance générique est désactivée, l’URL de redirection doit correspondre exactement à l’URL de rappel. Vous pouvez activer ou désactiver la correspondance de caractères génériques pour chaque URL de rappel dans les paramètres de votre application.

Les applications pour lesquelles une seule URL de rappel était activée avant le 3 août 2026 ont la correspondance par caractère générique activée pour cette URL de rappel. Cela préserve le comportement de redirection qui existait avant que la mise en correspondance avec caractères génériques ne devienne un paramètre configurable, et c’est pourquoi tous les OAuth apps et certains GitHub Apps créés avant cette date ont la mise en correspondance avec caractères génériques activée. Si votre application n’a pas besoin de mise en correspondance générique, nous vous recommandons de la désactiver.

URL de redirection de bouclage

Le paramètre redirect_uri facultatif peut également être utilisé pour les URL de bouclage, ce qui est utile pour les applications natives s’exécutant sur un ordinateur de bureau. Si l’application spécifie une URL de bouclage et un port, une fois l’application autorisée, les utilisateurs sont redirigés vers l’URL et le port fournis. redirect_uri n’a pas besoin de correspondre au port spécifié dans l’URL de rappel pour l’application.

Pour l’URL de rappel http://127.0.0.1/path, vous pouvez utiliser redirect_uri si votre application écoute sur le port 1234 :

http://127.0.0.1:1234/path

Notez qu’OAuth RFC recommande de ne pas utiliser localhost, mais d’utiliser à la place le littéral de bouclage 127.0.0.1 ou l’adresse IPv6 ::1.

Création de plusieurs jetons pour OAuth apps

Vous pouvez créer plusieurs jetons pour une combinaison utilisateur/application/étendue en réponse à des cas d’usage spécifiques.

Cela est utile si votre OAuth app flux de travail prend en charge un flux de travail qui utilise GitHub pour la connexion et nécessite uniquement des informations utilisateur de base. Un autre workflow peut nécessiter l’accès aux dépôts privés d’un utilisateur. À l’aide de plusieurs tokens, votre OAuth app peut exécuter le flux web pour chaque cas d’usage, en demandant uniquement les scopes nécessaires. Si un utilisateur utilise uniquement votre application pour se connecter, il n’est jamais nécessaire d’accorder l’accès OAuth app à ses dépôts privés.

Le nombre de jetons émis par combinaison utilisateur/application/étendue est limité à dix, avec une limite de taux de dix jetons créés par heure. Si une application crée plus de dix jetons pour le même utilisateur et les mêmes étendues, GitHub révoque l’un des jetons existants avec la même combinaison utilisateur/application/étendue, choisi dans cet ordre :

1. Jeton le plus ancien qui n’a jamais été utilisé et qui a été créé il y a plus d’une minute. Les jetons créés au cours de la dernière minute sont généralement protégés, afin qu’une application ait le temps d’utiliser un jeton qu’elle vient de créer.
2. S’il n’existe aucun jeton de ce type, mais qu’au moins un jeton a été utilisé, le jeton qui a été utilisé le moins récemment.
3. Si aucun jeton n’a été utilisé, le jeton le plus ancien, même s’il a été créé au cours de la dernière minute.

L’atteinte de la limite de taux horaire ne révoque pas votre jeton le plus ancien. Au lieu de cela, il déclenche une invite de ré-autorisation dans le navigateur, demandant à l’utilisateur de doubler vérifier les autorisations qu’il accorde à votre application. Cette invite est destinée à donner une pause à toute boucle infinie potentielle dans laquelle l’application est bloquée, car il n’y a pas de raison pour une application de demander dix jetons à l’utilisateur dans un délai d’une heure.

Orientation des utilisateurs pour la vérification de leur accès

Vous pouvez créer un lien vers les informations d’autorisation d’un OAuth app afin que les utilisateurs puissent consulter et révoquer les autorisations accordées à leur application.

Pour générer ce lien, vous aurez besoin de OAuth app vos client_idinformations reçues de GitHub lorsque vous avez inscrit l'application.

https://github.com/settings/connections/applications/:client_id

Dépannage

• Résolution des problèmes de demande d’autorisation
• Résolution des erreurs de demande de jeton d’accès pour l’application OAuth
• « Erreurs de flux d’appareils »
• Expiration et révocation des jetons

Pour aller plus loin

• À propos de l’authentification à GitHub