Sign up for an{" "}
Auth0 account
{" "}
or{" "}
console.log("log in")}>
log in
{" "}
to your existing account to integrate directly with your own tenant.
;
};
export const sections = [{
id: "conditions-requises",
title: "Conditions requises"
}, {
id: "recevoir-le-code-de-l-appareil",
title: "Recevoir le code de l’appareil"
}, {
id: "recevoir-le-code-de-l-appareil",
title: "Recevoir le code de l’appareil"
}, {
id: "demande-d-activation-de-l-appareil",
title: "Demande d’activation de l’appareil"
}, {
id: "interrogation-du-point-de-terminaison-du-jeton",
title: "Interrogation du point de terminaison du jeton"
}, {
id: "autorisation-de-l-utilisateur",
title: "Autorisation de l’utilisateur"
}, {
id: "recevoir-les-jetons",
title: "Recevoir les jetons"
}, {
id: "appeler-votre-api",
title: "Appeler votre API"
}, {
id: "jetons-d-actualisation",
title: "Jetons d’actualisation"
}, {
id: "dépannage",
title: "Dépannage"
}, {
id: "exemples-de-mises-en-œuvre",
title: "Exemples de mises en œuvre"
}, {
id: "limites",
title: "Limites"
}];
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](https://auth0.github.io/device-flow-playground/).
* 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.
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)](/docs/api/authentication#-post-oauth-device-code-) d’Authentication API du flux d’autorisation de l’appareil :
```bash cURL lines theme={null}
curl --request post \
--url 'https://{yourDomain}/oauth/device/code' \
--header 'content-type: application/x-www-form-urlencoded'
```
```csharp C# lines theme={null}
var client = new RestClient("https://{yourDomain}/oauth/device/code");
var request = new RestRequest(Method.POST);
request.AddHeader("content-type", "application/x-www-form-urlencoded");
IRestResponse response = client.Execute(request);
```
```go Go lines theme={null}
package main
import (
"fmt"
"net/http"
"io/ioutil"
)
func main() {
url := "https://{yourDomain}/oauth/device/code"
req, _ := http.NewRequest("post", url, nil)
req.Header.Add("content-type", "application/x-www-form-urlencoded")
res, _ := http.DefaultClient.Do(req)
defer res.Body.Close()
body, _ := ioutil.ReadAll(res.Body)
fmt.Println(res)
fmt.Println(string(body))
}
```
```java Java lines theme={null}
HttpResponse response = Unirest.post("https://{yourDomain}/oauth/device/code")
.header("content-type", "application/x-www-form-urlencoded")
.asString();
```
```javascript Node.JS lines theme={null}
var axios = require("axios").default;
var options = {
method: 'post',
url: 'https://{yourDomain}/oauth/device/code',
headers: {'content-type': 'application/x-www-form-urlencoded'}
};
axios.request(options).then(function (response) {
console.log(response.data);
}).catch(function (error) {
console.error(error);
});
```
```objc Obj-C lines theme={null}
#import
NSDictionary *headers = @{ @"content-type": @"application/x-www-form-urlencoded" };
NSMutableURLRequest *request = [NSMutableURLRequest requestWithURL:[NSURL URLWithString:@"https://{yourDomain}/oauth/device/code"]
cachePolicy:NSURLRequestUseProtocolCachePolicy
timeoutInterval:10.0];
[request setHTTPMethod:@"post"];
[request setAllHTTPHeaderFields:headers];
NSURLSession *session = [NSURLSession sharedSession];
NSURLSessionDataTask *dataTask = [session dataTaskWithRequest:request
completionHandler:^(NSData *data, NSURLResponse *response, NSError *error) {
if (error) {
NSLog(@"%@", error);
} else {
NSHTTPURLResponse *httpResponse = (NSHTTPURLResponse *) response;
NSLog(@"%@", httpResponse);
}
}];
[dataTask resume];
```
```php PHP lines theme={null}
$curl = curl_init();
curl_setopt_array($curl, [
CURLOPT_URL => "https://{yourDomain}/oauth/device/code",
CURLOPT_RETURNTRANSFER => true,
CURLOPT_ENCODING => "",
CURLOPT_MAXREDIRS => 10,
CURLOPT_TIMEOUT => 30,
CURLOPT_HTTP_VERSION => CURL_HTTP_VERSION_1_1,
CURLOPT_CUSTOMREQUEST => "post",
CURLOPT_HTTPHEADER => [
"content-type: application/x-www-form-urlencoded"
],
]);
$response = curl_exec($curl);
$err = curl_error($curl);
curl_close($curl);
if ($err) {
echo "cURL Error #:" . $err;
} else {
echo $response;
}
```
```python Python lines theme={null}
import http.client
conn = http.client.HTTPSConnection("")
headers = { 'content-type': "application/x-www-form-urlencoded" }
conn.request("post", "/{yourDomain}/oauth/device/code", headers=headers)
res = conn.getresponse()
data = res.read()
print(data.decode("utf-8"))
```
```ruby Ruby lines theme={null}
require 'uri'
require 'net/http'
require 'openssl'
url = URI("https://{yourDomain}/oauth/device/code")
http = Net::HTTP.new(url.host, url.port)
http.use_ssl = true
http.verify_mode = OpenSSL::SSL::VERIFY_NONE
request = Net::HTTP::Post.new(url)
request["content-type"] = 'application/x-www-form-urlencoded'
response = http.request(request)
puts response.read_body
```
```swift Swift lines theme={null}
import Foundation
let headers = ["content-type": "application/x-www-form-urlencoded"]
let request = NSMutableURLRequest(url: NSURL(string: "https://{yourDomain}/oauth/device/code")! as URL,
cachePolicy: .useProtocolCachePolicy,
timeoutInterval: 10.0)
request.httpMethod = "post"
request.allHTTPHeaderFields = headers
let session = URLSession.shared
let dataTask = session.dataTask(with: request as URLRequest, completionHandler: { (data, response, error) -> Void in
if (error != nil) {
print(error)
} else {
let httpResponse = response as? HTTPURLResponse
print(httpResponse)
}
})
dataTask.resume()
```
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
}
```
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`.
Pendant que votre application attend que l’utilisateur l’active, elle doit appeler le [point de terminaison POST /oauth/token](/docs/api/authentication#-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}'
```
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é.
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](/docs/api/authentication#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](/docs/tokens/id-tokens#id-token-payload). 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`.
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'
```
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](/docs/api/authentication#-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](https://auth0.com/docs/secure/tokens/refresh-tokens).
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.
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](https://auth0.github.io/device-flow-playground/)
* [AppleTV (Swift)](https://github.com/pushpabrol/auth0-device-flow-appletv) : application simple qui montre comment Auth0 peut être utilisé avec le flux d’autorisation d’un appareil AppleTV.
* [CLI (Node.js)](https://gist.github.com/panva/652c61e7d847e0ed99926c324fa91b36) : 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.
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](/docs/fr-ca/secure/application-credentials#application-authentication-methods) définie sur **None**
* Être [OIDC-conformant (conforme à l’OIDC)](/docs/dashboard/reference/settings-application#oauth)
* 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](https://manage.auth0.com/#) : apprenez à configurer et gérer votre locataire et vos applications Auth0
* [Auth0 Marketplace](https://marketplace.auth0.com/) : découvrez des intégrations que vous pouvez activer pour étendre les fonctionnalités d’Auth0
Sign up for an{" "}
Auth0 account
{" "}
or{" "}
console.log("log in")}>
log in
{" "}
to your existing account to integrate directly with your own tenant.
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é.