Libre-service machine-machine (M2M)

Si votre cas d’utilisation s’adresse à une audience non interactive comme des API ou des serveurs dorsaux, vous serez intégré avec une configuration machine-machine (M2M).

Utilisez le parcours d’intégration M2M si vous êtes concerné par (ou si vous utilisez) ce qui suit :

• Prise en charge des communications de service à service.

• Exécution de tâches planifiées ou de tâches cron sur des serveurs qui doivent accéder à des ressources protégées ou à des API.

• Appareils IoT autorisés à communiquer avec des services dorsaux ou des API.

• Couche API qui doit communiquer avec d’autres couches API sans intervention de l’utilisateur ou après l’expiration d’un jeton utilisateur.

• API privilégiée qui peut devoir être appelée avant qu’un utilisateur ne se soit authentifié (par exemple, à partir d’une action à partir d’une règle ou d’un script de base de données personnalisé dans votre locataire Auth0).

• Passerelle API pour gérer les services dorsaux.

• Applications non interactives ou des outils sans intervention humaine, tels que des démons ou des services dorsaux.

Ce guide vous accompagne dans la création de votre implémentation M2M dans Auth0. Nous vous proposons des recommandations, des bonnes pratiques et des concepts clés à prendre en compte.

• En matière d’architecture, nous vous recommandons de configurer Auth0 de manière à soutenir votre cycle de vie de développement logiciel ainsi que votre infrastructure actuelle.

• Dans la section Créer un compte, nous expliquons comment configurer une instance d’API dans Auth0 et créer une application afin de prendre en charge le flux d’authentification (ou le type d’autorisation) requis pour l’authentification machine-machine.

• Dans la section Authentification, nous détaillons le type d’autorisation à utiliser pour l’authentification, ainsi que les jetons d’accès et les permissions que vous pouvez définir.

• Dans la section Image de marque, nous expliquons où trouver les informations nécessaires pour configurer des domaines personnalisés, en fonction de la manière dont vous compter gérer les certificats.

• Dans la section Automatisations de déploiement, vous découvrirez nos outils conçus pour faciliter vos processus de déploiement.

• Dans la section Assurance qualité, vous trouverez des informations sur les tests unitaires et les contrôles de préparation disponibles dans le tableau de bord Auth0.

Avant de configurer votre compte et votre locataire Auth0, ou d’organiser les groupes et structures de vos services Auth0, il est recommandé de cartographier votre infrastructure existante. Cela vous permettra de tirer pleinement parti des capacités d’Auth0 au sein de votre écosystème actuel.

Comme indiqué dans les scénarios courants, il se peut que vous disposiez d’autres technologies non interactives dans vos domaines d’applications, de réseaux ou d’appareils M2M, qu’il est important de prendre en considération avant de procéder à la configuration d’Auth0. Pour consulter un exemple de scénario M2M, veuillez consulter Serveur + API. Pour mettre en place un laboratoire pratique avec Node et tester le déploiement de l’API, veuillez consulter notre référentiel GitHub.

Il pourra être utile de créer une visualisation de votre environnement technologique actuel ainsi que de planifier la manière dont Auth0 s’intègre à votre cycle de vie de développement logiciel (SDLC) actuel. Cela pourra vous aider à déterminer le nombre de locataires dont vous pourriez avoir besoin.

Avant de créer un nouveau compte ou de configurer votre premier locataire, il peut être utile de prendre en compte les éléments suivants :

• Comment vous partitionnez ou regroupez vos API pour appeler des points de terminaison spécifiques.

  • Cela peut déterminer l'audience et d’autres demandes sur les jetons d’accès.

• Tout consommateur tiers de votre ressource peut demander un jeton d’accès pour chaque appel. Les appels excessifs pourraient affecter votre limite anti-attaques.

Maintenant que vous avez un plan pour votre architecture, vous allez configurer votre compte Auth0 et vos locataires. Lorsque vous vous inscrivez aux services Auth0, vous créez votre premier locataire. Vous y configurez les actifs, les services et les ressources Auth0. Inscrivez-vous pour commencer.

Maintenant que vous avez un plan pour votre architecture, vous allez configurer votre compte Auth0 et Locataire.

Dans cette section, vous allez créez votre API dans Auth0.

Il est nécessaire d’établir une association entre votre application et votre API pour permettre à votre application de solliciter des jetons d’accès. Vous en apprendrez plus sur les autorisations client dans la section Authentification.

Lorsque vous appelez une API depuis une autre API, ou depuis toute situation où il n’y a pas de contexte d’utilisateur authentifié, vous aurez besoin d’un moyen d’autoriser l’application au lieu d’un utilisateur. Il s’agit d’un processus en une seule étape au cours duquel l’application est authentifiée (à l’aide d’un client_id et client_secret), puis autorisée en un seul appel.

Pour les applications ou services non interactifs à authentifier, vous devez sélectionner une autorisation client ou un flux d’authentification. Le Flux des identifiants client OAuth 2.0, ne nécessite pas d’interaction humaine et est particulièrement adapté aux applications M2M.

Vous pouvez utiliser Auth0 Dashboard ou Management API pour configurer le flux d’authentification, permettant ainsi de fournir des informations d’authentification client en échange d’un jeton d’accès.

Suivez les instructions de la section Mettre à jour les types d’autorisation pour utiliser Auth0 Dashboard ou Management API.

Dans l’authentification basée sur des jetons, les clients non interactifs fournissent client_id et client_secret dans un appel au point de terminaison du jeton Authentication API pour obtenir un jeton d’accès. Ce jeton d’accès permet d’accéder à votre API protégée.

Le profil ou format par défaut est le profil de jeton Auth0 associé à deux profils de jeton. Vous pouvez choisir de modifier le profil du jeton en choisissant RFC 9068. Pour en savoir plus, lisez Profils de jetons d’accès. Pour vérifier que le jeton est valide, votre API vérifiera les Algorithmes de signature. L’algorithme de signature par défaut est RSA256, un algorithme basé sur une clé.

Une demande au point de terminaison /oauth/token doit être similaire à l’exemple ci-dessous :

curl --request POST \
  --url 'https://{yourDomain}/oauth/token' \
  --header 'content-type: application/x-www-form-urlencoded' \
  --data grant_type=client_credentials \
  --data client_id=YOUR_CLIENT_ID \
  --data client_secret=YOUR_CLIENT_SECRET \
  --data audience=YOUR_API_IDENTIFIER

var client = new RestClient("https://{yourDomain}/oauth/token");
var request = new RestRequest(Method.POST);
request.AddHeader("content-type", "application/x-www-form-urlencoded");
request.AddParameter("application/x-www-form-urlencoded", "grant_type=client_credentials&client_id=YOUR_CLIENT_ID&client_secret=YOUR_CLIENT_SECRET&audience=YOUR_API_IDENTIFIER", ParameterType.RequestBody);
IRestResponse response = client.Execute(request);

package main

import (
	"fmt"
	"strings"
	"net/http"
	"io/ioutil"
)

func main() {

	url := "https://{yourDomain}/oauth/token"

	payload := strings.NewReader("grant_type=client_credentials&client_id=YOUR_CLIENT_ID&client_secret=YOUR_CLIENT_SECRET&audience=YOUR_API_IDENTIFIER")

	req, _ := http.NewRequest("POST", url, payload)

	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/token")
  .header("content-type", "application/x-www-form-urlencoded")
  .body("grant_type=client_credentials&client_id=YOUR_CLIENT_ID&client_secret=YOUR_CLIENT_SECRET&audience=YOUR_API_IDENTIFIER")
  .asString();

var axios = require("axios").default;

var options = {
  method: 'POST',
  url: 'https://{yourDomain}/oauth/token',
  headers: {'content-type': 'application/x-www-form-urlencoded'},
  data: new URLSearchParams({
    grant_type: 'client_credentials',
    client_id: 'YOUR_CLIENT_ID',
    client_secret: 'YOUR_CLIENT_SECRET',
    audience: 'YOUR_API_IDENTIFIER'
  })
};

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

NSMutableData *postData = [[NSMutableData alloc] initWithData:[@"grant_type=client_credentials" dataUsingEncoding:NSUTF8StringEncoding]];
[postData appendData:[@"&client_id=YOUR_CLIENT_ID" dataUsingEncoding:NSUTF8StringEncoding]];
[postData appendData:[@"&client_secret=YOUR_CLIENT_SECRET" dataUsingEncoding:NSUTF8StringEncoding]];
[postData appendData:[@"&audience=YOUR_API_IDENTIFIER" dataUsingEncoding:NSUTF8StringEncoding]];

NSMutableURLRequest *request = [NSMutableURLRequest requestWithURL:[NSURL URLWithString:@"https://{yourDomain}/oauth/token"]
                                                       cachePolicy:NSURLRequestUseProtocolCachePolicy
                                                   timeoutInterval:10.0];
[request setHTTPMethod:@"POST"];
[request setAllHTTPHeaderFields:headers];
[request setHTTPBody:postData];

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

$curl = curl_init();

curl_setopt_array($curl, [
  CURLOPT_URL => "https://{yourDomain}/oauth/token",
  CURLOPT_RETURNTRANSFER => true,
  CURLOPT_ENCODING => "",
  CURLOPT_MAXREDIRS => 10,
  CURLOPT_TIMEOUT => 30,
  CURLOPT_HTTP_VERSION => CURL_HTTP_VERSION_1_1,
  CURLOPT_CUSTOMREQUEST => "POST",
  CURLOPT_POSTFIELDS => "grant_type=client_credentials&client_id=YOUR_CLIENT_ID&client_secret=YOUR_CLIENT_SECRET&audience=YOUR_API_IDENTIFIER",
  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("")

payload = "grant_type=client_credentials&client_id=YOUR_CLIENT_ID&client_secret=YOUR_CLIENT_SECRET&audience=YOUR_API_IDENTIFIER"

headers = { 'content-type': "application/x-www-form-urlencoded" }

conn.request("POST", "/{yourDomain}/oauth/token", payload, headers)

res = conn.getresponse()
data = res.read()

print(data.decode("utf-8"))

require 'uri'
require 'net/http'
require 'openssl'

url = URI("https://{yourDomain}/oauth/token")

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'
request.body = "grant_type=client_credentials&client_id=YOUR_CLIENT_ID&client_secret=YOUR_CLIENT_SECRET&audience=YOUR_API_IDENTIFIER"

response = http.request(request)
puts response.read_body

import Foundation

let headers = ["content-type": "application/x-www-form-urlencoded"]

let postData = NSMutableData(data: "grant_type=client_credentials".data(using: String.Encoding.utf8)!)
postData.append("&client_id=YOUR_CLIENT_ID".data(using: String.Encoding.utf8)!)
postData.append("&client_secret=YOUR_CLIENT_SECRET".data(using: String.Encoding.utf8)!)
postData.append("&audience=YOUR_API_IDENTIFIER".data(using: String.Encoding.utf8)!)

let request = NSMutableURLRequest(url: NSURL(string: "https://{yourDomain}/oauth/token")! as URL,
                                        cachePolicy: .useProtocolCachePolicy,
                                    timeoutInterval: 10.0)
request.httpMethod = "POST"
request.allHTTPHeaderFields = headers
request.httpBody = postData as Data

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

La réponse devrait être similaire à l’exemple ci-dessous :

HTTP/1.1 200 OK
Content-Type: application/json
{
  "access_token":"eyJz93a...k4laUWw",
  "token_type":"Bearer",
  "expires_in":86400
}

Vos jetons d’accès ont une limite de durée de validité. Étant donné que vos communications se déroulent sur le canal d'appui, l’utilisation de jetons d’actualisation pour prolonger les sessions n’est pas possible. Il est donc recommandé de configurer vos jetons d’accès avec un délai d’expiration d’une heure. Il vous faudra peut-être trouver le bon équilibre entre sécurité et performance en fonction des besoins spécifiques de votre environnement. Pour en savoir plus, veuillez consulter Mettre à jour la durée de vie du jeton d’accès.

Avant que tout client ou service non interactif n’appelle votre API, vous devez définir les autorisations ou les portées autorisées par votre API. Vous pouvez définir les permissions dans Auth0 Dashboard afin de les inclure dans votre demande à l’Authentication API. Pour lire plus d’exemples de façons d’utiliser les permissions des API, veuillez consulter Permissions des API.

Pour configurer les permissions, veuillez consulter les instructions Ajouter des autorisations API pour Auth0 Dashboard ou utilisez l’exemple fourni pour Management API.

Même si vous offrez des services à des clients non interactifs ou à des clients opérant sur le canal d’appui, vous pouvez toujours personnaliser votre expérience pour l’aligner sur l’apparence de votre marque existante.

Auth0 prend en charge l’utilisation de domaines personnalisés lors de l’appel du point de terminaison /authorize pour demander des jetons d’accès.

1. Pour configurer votre domaine personnalisé avec des certificats gérés par Auth0, suivez les instructions fournies à la section Configurer des domaines personnalisés avec des certificats gérés par Auth0.

   1. Si vous souhaitez gérer vos propres certificats, suivez les instructions fournies à la section Configurer des domaines personnalisés avec des certificats autogérés.

      Vous devez avoir un abonnement Enterprise pour gérer les certificats dans votre domaine personnalisé. Pour en savoir plus, lisez Tarification et connexion Auth0.

2. Lisez Configuration de l’API avec des domaines personnalisés. Vous devrez peut-être ajuster vos paramètres API pour intégrer un domaine personnalisé.

Si vous rencontrez des problèmes avec votre domaine personnalisé, veuillez consulter la section Dépannage des domaines personnalisés.

Auth0 offre une prise en charge pour plusieurs options différentes concernant les approches d’automatisation du déploiement que vous pouvez utiliser, chacune pouvant être utilisée conjointement avec l’autre.

Comme indiqué dans la section Architecture, il est recommandé d’avoir des locataires Auth0 distincts pour le développement, les tests et la production. Ces locataires doivent partager des configurations identiques pour garantir la qualité et les tests. Cependant, des erreurs peuvent survenir si des configurations incompatibles existent entre vos différents environnements. Par exemple, chaque environnement aura des ID client et des secrets client différents.

Pour réduire les erreurs de non-concordance, vous pouvez utiliser l’outil Deploy CLI afin d’intégrer votre instance Auth0 à votre pipeline CI/CD existant. Avec le remplacement dynamique des mots-clés, vous pouvez substituer les variables d’environnement des locataires partageant des configurations similaires. Pour en savoir plus, veuillez consulter Outil Deploy CLI et Remplacement de mots-clés.

L’extension Real-time Webtask Logs affiche tous les journaux du code personnalisé en temps réel, y compris la sortie console.log et autres exceptions. Si vous utilisez Auth0 Actions ou une autre logique personnalisée, vous pouvez utiliser cette extension pour déboguer et dépanner les problèmes. Pour en savoir plus sur l’installation et la configuration, veuillez consulter Extension des journaux WebTask en temps réel.

L’assurance qualité est importante pour identifier les problèmes avant la mise en service. En fonction de la nature de votre projet, il existe plusieurs types différents de tests d’assurance qualité que vous voudrez envisager dans le cadre de votre intégration avec Auth0 :

• Comment votre API se comportera-t-elle lorsqu’elle seront soumise à des charges de production inattendues?

• Comment vos limites anti-attaques seront-elles affectées par les applications tierces?

Si vous n’utilisez pas les gadgets logiciels ou les fonctionnalités Auth0, comme la connexion universelle, vous ne profiterez pas des meilleures pratiques d’utilisation et d’accessibilité intégrées, prêtes à l’emploi sur une large gamme de navigateurs et d’appareils. Pour assurer que les exigences fonctionnelles sont respectées et que les événements inattendus sont gérés correctement, des conseils sont fournis pour tester l’intégration entre votre ou vos applications et Auth0, et pour des tests unitaires de modules d’extensibilité individuels, comme Auth0 Actions. Nous vous recommandons également de consulter la politique de tests de pénétration d’Auth0 et les tests simulés complets que vous pouvez exploiter en conjonction avec notre politique de test de charge pour garantir que votre/vos application(s) fonctionnent sous une charge inattendue.

Les tests unitaires vérifient les unités d’extensibilité, comme Auth0 Actions. Si vous utilisez du code personnalisé, nous vous recommandons d’utiliser un cadre d'applications (tel que Mocha) pour tester le code supplémentaire avant le déploiement.

Pour trouver un équilibre entre la politique de test de charge d’Auth0 et votre souhait de réaliser des tests de charge, il est courant de créer un test simulé des points de terminaison d’Auth0. Cette pratique est précieuse pour garantir que votre application fonctionne avec les interfaces attendues sans avoir à restreindre vos tests, et des outils tels que MockServer, JSON Server ou même Postman peuvent être utilisés à cette fin.

Notre section Déployer et surveiller fournit des conseils sur les meilleures pratiques de déploiement. Nous vous recommandons de lire Vérifications de prédéploiement, en particulier la section traitant des Vérifications de préparation Auth0 Dashboard intégrées.

Pour consulter la Vérification de préparation, sélectionnez le menu déroulant sous le nom de votre locataire et l’étiquette environnementale dans Auth0 Dashboard > Run Readiness Checks (Exécuter les vérifications de préparation).

Vous pouvez utiliser le filtre pour appliquer les vérifications de préparation aux applications sélectionnées. Ces vérifications ne s’appliquent pas à vos API configurées.

Pour les vérifications qui ne s’appliquent pas à votre configuration spécifique, vous pouvez sélectionner Dismiss (Rejeter) pour les retirer des résultats finaux.

Nous vous conseillons de lire Bonnes pratiques de déploiement pour les dernières vérifications avant de passer en situation réelle et de tirer parti des Logs (Journaux) pour surveiller vos services.

• Présentation d’Auth0
• Aperçu de solution (Applications serveur + API)
• Effectuer une requête à votre API à l’aide du Flux des identifiants client
• Récupérer les événements de journal à l’aide de Management API
• Obtenir des jetons d’accès à Management API pour la production