Yggdrasil

Cette page décrit du contenu qui n'existe que dans d'anciennes versions de l'édition Java. 

Le système d'authentification Yggdrasil a été remplacé par l'authentification Microsoft.

Avec la sortie de l'édition Java 1.6.1, Mojang a introduit un nouveau système d'authentification appelé Yggdrasil, qui a remplacé l'ancien système d'authentification. Ce système d'authentification est également utilisé dans l'autre jeu de Mojang, Scrolls. Selon Mojang, le système d'authentification Yggdrasil doit être adopté par les développeurs pour l'implémentation d'une connexion personnalisée, mais il est fortement déconseillé de collecter les informations d'identification des utilisateurs. Ce système d'authentification a été remplacé par l'authentification Microsoft.

Les requêtes du système d'authentification Yggdrasil sont adressées au serveur suivant :

https://authserver.mojang.com

Pour garantir le succès des requêtes, elles doivent respecter les directives suivantes :

• Utiliser la méthode de requête POST
• Inclure un en-tête Content-Type défini à application/json
• Contenir un dictionnaire encodé en JSON comme charge utile

En cas de requête réussie, le serveur renverra :

• Un code de statut HTTP 2XX pour indiquer le succès
• Une charge utile vide ou un dictionnaire encodé en JSON tel que spécifié dans la documentation de l'API

En cas d'échec de la requête, le serveur renverra :

• Un code de statut HTTP autre que 2XX pour indiquer l'échec
• Un dictionnaire encodé en JSON suivant le format ci-dessous :

{
    "error": "Brève description de l'erreur",
    "cause": "Cause de l'erreur" // optionnel
    "errorMessage": "Description plus longue qui peut être affichée à l'utilisateur",
}

Voici des exemples de scénario d'erreur qui peuvent se produire lors de l'utilisation du système d'authentification Yggdrasil :

Authentifie un utilisateur à l'aide de son mot de passe.

/authenticate

{
    "agent": {                                    // Minecraft par défaut
        "name": "Minecraft",                      // Pour l'autre jeu de Mojang, Scrolls, "Scrolls" doit être utilisé
        "version": 1                              // Ce nombre peut être augmenté par
                                                  // le client vanilla dans le futur
    },
    "username": "nom du compte Mojang",           // Peut être une adresse e-email ou un nom de joueur
                                                  // pour les comptes non migrés
    "password": "mot de passe du compte Mojang",
    "clientToken": "identifiant du client",       // optionnel
    "requestUser": true                           // optionnel ; false par défaut ; true ajoute l'objet de l'utilisateur à la réponse
}

Le clientToken doit être un identifiant généré de manière aléatoire et doit être identique pour chaque requête. Le launcher vanilla génère un UUID (version 4) aléatoire lors de la première exécution et le sauvegarde, puis le réutilise pour chaque requête ultérieure. En cas d'omission, le serveur génère un jeton aléatoire basé sur la méthode Java UUID.toString() qui doit alors être stocké par le client. Cependant, cela invalide également tous les jetons d'accès précédemment acquis pour cet utilisateur sur tous les clients.

{
    "user": {
        "username": "utilisateur@exemple.email", // le nom d'utilisateur du compte pour les anciens comptes
        "properties": [
            {
                "name": "preferredLanguage",
                "value": "en-us"
            },
            {
                "name": "registrationCountry",
                "value": "pays" // pays en 2 lettres (par exemple, US)
            }
        ],
        "id": "chaîne de caractères hexadécimale" // Il s'agit du remoteID de l'utilisateur
    },
    "clientToken": "identifiant du client",
    "accessToken": "jeton d'accès aléatoire", // hexadécimal ou jeton web en JSON (non confirmé) [Le jeton d'accès normal peut être trouvé dans la charge utile de JWT (deuxième partie séparée par un '.' en tant qu'objet JSON encodé en Base64), dans la clé "yggt"]
    "availableProfiles": [
        {
            "name": "nom d'utilisateur du joueur",
            "id": "chaîne de caractères hexadécimale" // UUID du compte
        }
    ],
    "selectedProfile": {
        "name": "nom d'utilisateur du joueur",
        "id": "chaîne de caractères hexadécimale" // UUID du compte
    }
}

Note : Si un utilisateur souhaite rester connecté sur son ordinateur, il est fortement conseillé de stocker le jeton d'accès reçu au lieu du mot de passe lui-même.

Actuellement, chaque compte n'a qu'un seul profil, mais plusieurs profils par compte sont prévus dans le futur. Si un utilisateur tente de se connecter à un compte Mojang valide sans licence Minecraft associée, l'authentification réussit, mais la réponse ne contient pas de champ selectedProfile, et le tableau availableProfiles est vide.

Quelques cas ont été observés où Mojang renvoie une valeur null pour des tentatives d'actualisation échouées sur des anciens comptes. L'erreur réelle liée à la réponse nulle n'est pas claire et cela est extrêmement rare, mais les implémentations doivent prendre en compte une sortie nulle de la réponse.

Cet endpoint est extrêmement limité en termes de débit : plusieurs requêtes /authenticate pour le même compte dans un court laps de temps (par exemple 3 requêtes en quelques secondes), même avec le bon mot de passe, finissent par entraîner une réponse Invalid credentials.. Cette erreur disparaît quelques secondes plus tard.

Actualise un jeton d'accès valide. Il peut être utilisé pour garder un utilisateur connecté entre les sessions de jeu et est préférable au stockage du mot de passe de l'utilisateur dans un fichier.

/refresh

{
    "accessToken": "jeton d'accès valide",
    "clientToken": "identifiant du client",  // Cela doit être identique à celui utilisé pour
                                             // obtenir le jeton d'accès en premier lieu
    "selectedProfile": {                     // optionnel ; l'envoyer entraînera une erreur
        "id": "identifiant du profil",       // hexadécimal
        "name": "nom du joueur"
    },
    "requestUser": true                      // optionnel ; false par défaut ; true ajoute l'objet de l'utilisateur à la réponse
}

Note : Le jeton d'accès fourni est invalidé.

{
    "accessToken": "jeton d'accès aléatoire",     // hexadécimal
    "clientToken": "identifiant du client",       // identique à celui reçu
    "selectedProfile": {
        "id": "identifiant du client",            // hexadécimal
        "name": "nom du joueur"
    },
    "user": {                                     // présent seulement si requestUser valait true dans la charge utile de la requête
        "username": "utilisateur@exemple.email",  // e-mail pour les comptes Mojang ou nom d'utilisateur du compte pour les anciens comptes Minecraft
        "id": "identifiant de l'utilisateur",     // hexadécimal
        "properties": [
            {
                "name": "preferredLanguage",      // peut ne pas être présent pour tous les comptes
                "value": "en"                     // format de paramètres régionaux Java (https://docs.oracle.com/javase/8/docs/api/java/util/Locale.html#toString--)
            },
            {
                "name": "twitch_access_token",    // présent seulement si un compte Twitch est associé (voir https://account.mojang.com/me/settings)
                "value": "jeton OAuth de Twitch"  // jeton OAuth 2.0 ; alphanumérique ; par exemple https://api.twitch.tv/kraken?oauth_token=[...]
                                                  // l'API Twitch API est documentée ici : https://github.com/justintv/Twitch-API
            }
        ]
    }
}

Vérifie si un jeton d'accès est utilisable pour l'authentification avec un serveur Minecraft. Le launcher Minecraft (à partir de la version 1.6.13) appelle cet endpoint au démarrage pour vérifier que son jeton sauvegardé est toujours utilisable, et appelle /refresh si cela renvoie une erreur.

Notez qu'un jeton d'accès peut être inutilisable pour l'authentification avec un serveur Minecraft, mais être tout de même suffisant pour /refresh. Cela se produit principalement lorsqu'un utilisateur a utilisé un autre client (par exemple, a joué à Minecraft sur un autre PC avec le même compte). Il semble que seul le dernier jeton d'accès obtenu pour un compte donné puisse être utilisé de manière fiable pour l'authentification (l'avant-dernier jeton semble également rester valide, mais il ne faut pas s'y fier).

/validate peut être appelé avec ou sans clientToken. Si un clientToken est fourni, il doit correspondre à celui utilisé pour obtenir le jeton d'accès. Le launcher Minecraft envoie un clientToken à /validate.

/validate

{
    "accessToken": "jeton d'accès valide",
    "clientToken": "jeton du client associé" // optionnel, voir ci-dessus
}

Renvoie une charge utile vide (204 No Content) en cas de succès, un JSON d'erreur avec le statut 403 Forbidden autrement.

Invalide les jetons d'accès à l'aide du nom d'utilisateur et du mot de passe d'un compte.

/signout

{
    "username": "nom du compte Mojang",
    "password": "mot de passe du compte Mojang"
}

Renvoie une charge utile vide en cas de succès.

Invalide les jetons d'accès à l'aide d'une paire client/jeton d'accès.

/invalidate

{
    "accessToken": "jeton d'accès valide",
    "clientToken": "identifiant du client"   // Cela doit être identique à celui utilisé pour
                                             // obtenir le jeton d'accès en premier lieu
}

Renvoie une charge utile vide en cas de succès.

• Wrapper Yggdrasil complet en Kotlin
• Wrapper Yggdrasil complet en Java

Ce fichier est sous licence Creative Commons Attribution-ShareAlike 3.0. 

Cette page a été importée depuis wiki.vg ou est un dérivé d'une telle page. Ainsi, la licence habituelle du wiki ne s'applique pas.
Les œuvres dérivées doivent être concédées sous licence en utilisant la même licence ou une licence compatible.