Flux d’autorisation d’appareil

Ce tutoriel explique comment appeler votre API à partir d’un appareil dont les entrées sont limitées, à l’aide du flux d’autorisation d’appareil. Nous vous recommandons de vous connecter pour suivre ce démarrage rapide avec les exemples configurés pour votre compte.Pour une expérience interactive, vous pouvez utiliser Terrain de jeu du flux d’appareil.

Conditions requises

Enregistrez une application native.
Assurez-vous que l’option Conforme à l’OIDC est activée. Pour plus d’informations, consultez Authentification conforme à OIDC.
Ajoutez Device Code (Code de l’appareil) aux types d’autorisation de l’application. Pour plus d’informations, consultez Mettre à jour les types d’autorisation.
Ajoutez Refresh Token (Jeton d’actualisation) aux types d’autorisation de l’application si vous souhaitez activer les jetons d’actualisation.
Configurez et activez au moins une connexion pour l’application.
Enregistrez votre application avec Auth0.
- Activez l’option Autoriser l’accès hors ligne si vous utilisez des jetons d’actualisation. Pour en savoir plus, veuillez consulter Paramètres API.
Configure Device User Code Settings (Configurez les paramètres du code utilisateur de l’appareil) pour définir le jeu de caractères, le format et la longueur de votre code utilisateur généré de manière aléatoire.

Recevoir le code de l’appareil

Lorsque l’utilisateur démarre l’application de l’appareil et souhaite l’autoriser, votre application doit demander un code d’appareil à Auth0 Authentication API pour l’associer à la session de l’utilisateur.Pour obtenir le code de l’appareil, votre application doit appeler le Authorize endpoint (Point de terminaison d’autorisation) d’Authentication API du flux d’autorisation de l’appareil :

curl --request post \
  --url 'https://dev-gja8kxz4ndtex3rq.us.auth0.com/oauth/device/code' \
  --header 'content-type: application/x-www-form-urlencoded'

Recevoir le code de l’appareil

L’application de l’appareil devrait recevoir une réponse HTTP 200 et une charge utile similaire à celle-ci :

{
"device_code": "GmRh...k9eS",
"user_code": "WDJB-MJHT",
"verification_uri": "https://my-tenant.auth0.com/device",
"verification_uri_complete": "https://my-tenant.auth0.com/device?user_code=WDJB-MJHT",
"expires_in": 900,
"interval": 5
}

Demande d’activation de l’appareil

Après avoir reçu le device_code et le user_code, votre application doit demander à l’utilisateur de se rendre au verification_uri et de saisir le user_code.

Le device\_code n’est pas destiné directement à l’utilisateur et ne doit pas être affiché pendant l’interaction afin de ne pas créer de confusion chez l’utilisateur.

Lorsque vous créez une CLI, vous pouvez ignorer cette étape et ouvrir directement le navigateur avec verification\_uri\_complete.

Interrogation du point de terminaison du jeton

Pendant que votre application attend que l’utilisateur l’active, elle doit appeler le point de terminaison POST /oauth/token d’Authentication API de manière intermittente et traiter la réponse de manière appropriée.

Assurez-vous que votre application attend la durée de interval (en secondes) ou jusqu’à ce qu’elle reçoive une réponse positive, la durée la plus longue étant retenue, afin d’éviter les problèmes de latence du réseau.

curl --request POST \
--url 'https://{yourDomain}/oauth/token' \
--header 'content-type: application/x-www-form-urlencoded' \
--data grant_type=urn:ietf:params:oauth:grant-type:device_code \
--data device_code=AUTH0_SCOPES \
--data 'client_id={yourClientId}'

Autorisation de l’utilisateur

L’utilisateur peut soit balayer le code QR, soit ouvrir la page d’activation et saisir le code d’utilisateur :

Une page de confirmation s’affiche pour que l’utilisateur confirme qu’il s’agit du bon appareil :

L’utilisateur terminera la transaction en se connectant. Cette étape peut comprendre un ou plusieurs des procédés suivant :

Authentifier l’utilisateur
Redirection de l’utilisateur vers un fournisseur d’identité pour gérer l’authentification
Vérification des sessions actives d’authentification unique (SSO)
Obtenir le consentement de l’utilisateur pour l’appareil, à moins qu’il n’ait été donné au préalable

Une fois l’authentification et le consentement obtenus, la demande de confirmation s’affiche :

À ce stade, l’utilisateur s’est authentifié et l’appareil a été autorisé.

Recevoir les jetons

Une fois que l’utilisateur a autorisé l’application, celle-ci reçoit une réponse HTTP 200 et la charge utile suivante :

{
"access_token": "eyJz93a...k4laUWw",
"refresh_token": "GEbRxBN...edjnXbL",
"id_token": "eyJ0XAi...4faeEoQ",
"token_type": "Bearer",
"expires_in": 86400
}

Vous devez valider vos jetons avant de les enregistrer. Pour en savoir plus, consultez Valider les jetons d’accès et Valider les jetons d’ID.

Les jetons d’accès sont utilisés pour appeler le point de terminaison Get User Info de Authentication API (si l’application de votre appareil a demandé la permission openid) ou l’API définie par le paramètre audience. Si vous appelez votre propre API, votre application doit vérifier le jeton d’accès avant de l’utiliser.Les jetons d’ID contiennent des informations sur l’utilisateur qui doivent être décodées et extraites. Authentication API ne renvoie un id_token que si l’application de votre appareil a demandé la permission openid.Les jetons d’actualisation sont utilisés pour obtenir un nouveau jeton d’accès ou un nouveau jeton d’ID après l’expiration du précédent. Authentication API ne renvoie un refresh_token que si le paramètre Autoriser l’accès hors ligne est activé pour l’API indiquée par le paramètre public et que l’application de votre appareil a demandé la permission offline_access.

Appeler votre API

Pour appeler votre API, votre application doit transmettre le jeton d’accès en tant que jeton de porteur dans l’en-tête Authorization de votre requête HTTP.

curl --request GET \
--url https://myapi.com/api \
--header 'authorization: Bearer AUTH0_API_ACCESS_TOKEN' \
--header 'content-type: application/json'

Jetons d’actualisation

Pour obtenir un nouveau jeton d’accès pour un utilisateur, l’application de votre appareil peut appeler le point de terminaison POST /oauth/token de l’API d’authentication avec le paramètre refresh_token.

curl --request POST \
--url 'https://{yourDomain}/oauth/token' \
--header 'content-type: application/x-www-form-urlencoded' \
--data grant_type=refresh_token \
--data 'client_id={yourClientId}' \
--data 'client_secret={yourClientSecret}' \
--data refresh_token=AUTH0_REFRESH_TOKEN

Si la requête a réussi, l’application de votre appareil reçoit une réponse HTTP 200 avec la charge utile suivante :

{
"access_token": "eyJ...MoQ",
"expires_in": 86400,
"scope": "openid offline_access",
"id_token": "eyJ...0NE",
"token_type": "Bearer"
}

Pour en savoir plus sur les jetons d’actualisation, veuillez consulter Jetons d’actualisation.

Dépannage

Les journaux de locataires sont créés pour toutes les interactions qui ont lieu et peuvent être utilisés pour résoudre les problèmes.

Code	Nom	Description
`fdeaz`	Échec de la demande d’autorisation de l’appareil
`fdeac`	Échec de l’activation de l’appareil
`fdecc`	L’utilisateur a annulé la confirmation de l’appareil
`fede`	Échec de l’échange	Code d’appareil contre un jeton d’accès
`sede`	Échange réussi	code d’appareil contre un jeton d’accès

Réponses des jetons

Il est possible de recevoir plusieurs réponses HTTP 4xx différentes pendant que vous attendez que l’utilisateur autorise l’appareil.

Autorisation en attente

Vous verrez cette erreur pendant que vous attendez que l’utilisateur agisse. Poursuivez l’interrogation en utilisant interval suggéré dans l’étape précédente de ce tutoriel.

`HTTP 403`
{
"error": "authorization_pending",
"error_description": "..."
}

Ralentissement

L’interrogation est trop rapide. Ralentissez et utilisez l’intervalle suggéré dans l’étape précédente de ce tutoriel. Pour éviter de recevoir cette erreur en raison de la latence du réseau, vous devez commencer à compter chaque intervalle après la réception de la réponse de la dernière demande d’interrogation.

`HTTP 429`
{
"error": "slow_down",
"error_description": "..."
}

Jeton expiré

L’utilisateur n’a pas autorisé l’appareil assez rapidement, par conséquent le device_code a expiré. Votre application doit avertir l’utilisateur que le flux a expiré et l’inviter à le réinitialiser.

Le expired\_token n’est renvoyé qu’une seule fois. Ensuite, le point de terminaison renvoie l’erreur invalid\_grant.

`HTTP 403`
{
"error": "expired_token",
"error_description": "..."
}

Accès refusé

Si l’accès est refusé, vous recevez :

`HTTP 403`
{
"error": "access_denied",
"error_description": "..."
}

Cela peut se produire pour diverses raisons, notamment :

l’utilisateur a refusé d’autoriser l’appareil,
le serveur d’autorisation a refusé la transaction.
Une Action configurée a refusé l’accès.

Exemples de mises en œuvre

Consultez les exemples ci-dessous pour savoir comment mettre en œuvre ce flux dans des applications réelles.

Terrain de jeu du flux de l’appareil
AppleTV (Swift) : application simple qui montre comment Auth0 peut être utilisé avec le flux d’autorisation d’un appareil AppleTV.
CLI (Node.js) : exemple de mise en œuvre d’une CLI qui utilise le flux d’autorisation de l’appareil au lieu du flux du code d’autorisation. La principale différence est que votre CLI n’a pas besoin d’héberger un serveur Web et d’écouter sur un port.

Limites

Pour utiliser le flux d’autorisation de l’appareil, l’application de l’appareil doit :

Prendre en charge l’indication du nom du serveur (SNI)
Être une Native Application (Application native)
Avoir la Authentication Method définie sur None
Être OIDC-conformant (conforme à l’OIDC)
Ne pas être créée au moyen de Dynamic Client Registration (Enregistrement dynamique des clients)

En outre, le flux d’autorisation de l’appareil ne permet pas :

Les Social Connections (Connexions via réseau social) qui utilisent les Auth0 developer keys (Clés de développeur Auth0), sauf si vous utilisez l’Universal Login experience (Expérience de connexion universelle)
Les paramètres de la chaîne de requête doivent être accessibles à partir d’une page de connexion ou d’actions hébergées.

Étapes suivantes

Beau travail! Si vous en êtes arrivé là, vous devriez avoir la connexion, la déconnexion et les informations de profil utilisateur actives dans votre application.Cela conclut notre tutoriel de démarrage rapide, mais il y a tellement plus à explorer. Pour en savoir plus sur ce que vous pouvez faire avec Auth0, consultez :

Auth0 Dashboard : apprenez à configurer et gérer votre locataire et vos applications Auth0
Auth0 Marketplace : découvrez des intégrations que vous pouvez activer pour étendre les fonctionnalités d’Auth0

Application à page unique

Application Web classique

Application Native/Mobile

Dorsale/API

Flux d’autorisation d’appareil

Conditions requises

Recevoir le code de l’appareil

Recevoir le code de l’appareil

Demande d’activation de l’appareil

Interrogation du point de terminaison du jeton

Autorisation de l’utilisateur

Recevoir les jetons

Appeler votre API

Jetons d’actualisation

Dépannage

Réponses des jetons

Autorisation en attente

Ralentissement

Jeton expiré

Accès refusé

Exemples de mises en œuvre

Limites

Étapes suivantes

Application à page unique

Application Web classique

Application Native/Mobile

Dorsale/API

Conditions requises

Recevoir le code de l’appareil

Recevoir le code de l’appareil

Demande d’activation de l’appareil

Interrogation du point de terminaison du jeton

Autorisation de l’utilisateur

Recevoir les jetons

Appeler votre API

Jetons d’actualisation

Dépannage

​Réponses des jetons

​Autorisation en attente

​Ralentissement

​Jeton expiré

​Accès refusé

Exemples de mises en œuvre

Limites

​Étapes suivantes

Réponses des jetons

Autorisation en attente

Ralentissement

Jeton expiré

Accès refusé

Étapes suivantes