• 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) d’Authentication API du flux d’autorisation de l’appareil :

curl --request post \
--url 'https://{yourDomain}/oauth/device/code' \
--header 'content-type: application/x-www-form-urlencoded'

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);

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))
}

HttpResponse<String> response = Unirest.post("https://{yourDomain}/oauth/device/code")
.header("content-type", "application/x-www-form-urlencoded")
.asString();

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);
});

#import <Foundation/Foundation.h>
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(@&quot;%@&quot;, error);

                                            } else {

                                                NSHTTPURLResponse *httpResponse = (NSHTTPURLResponse *) response;

                                                NSLog(@&quot;%@&quot;, httpResponse);

                                            }

                                        }];

[dataTask resume];

$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;
}

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"))

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

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.

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.

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
}

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.

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 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.

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.

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.

`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

• 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.

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.