User:Lzs/Authentication(Chinese)

(Is being translated into Chinese)

在Minecraft 1.6 中引入了一种名为 Yggdrasil 的新身份验证方案，完全取代了旧版认证系统。Mojang的其他游戏《Scrolls》也使用这种认证方式。 Mojang 表示 此身份验证系统应该被使用在每一个自定义登录上，但 绝不应从用户那里收集证书。

请求格式

所有请求是由以下服务器发往 Yggdrasil：

https://authserver.mojang.com

进一步说，他们预计将满足以下规则：

• 是 POST 请求
• Have the Content-Type header set to application/json
• Contain a JSON-encoded dictionary as payload

如果请求成功服务器将响应：

• 状态码 200
• A JSON-encoded dictionary according to the specifications below

If however a request fails, the server will respond with:

• An appropriate, non-200 HTTP status code
• 一个 JSON-编码字典格式如下:

{
    "error": "Short description of the error",
    "errorMessage": "Longer description which can be shown to the user",
    "cause": "Cause of the error" // optional
}

错误

这些都是一些可能遇到的错误:

错误	原因	错误提示	注释
Method Not Allowed		请求中指定的方法是不允许的，因为资源标识来自URI请求。	收到POST请求以外的数据。
Not Found		服务器并没有发现任何匹配此请求的URI。	被呼叫的端口不存在。
ForbiddenOperationException	UserMigratedException	无效的证书。帐户迁移,使用电子邮件作为用户名。
ForbiddenOperationException		无效的证书。无效的用户名或密码。
ForbiddenOperationException		无效的证书。	此用户名近期尝试太多次登录(查看/authenticate)。注意，用户名和密码可能仍然是有效的！
ForbiddenOperationException		无效的令牌。	accessToken 是无效的。
IllegalArgumentException		访问令牌(Access token)已有一个指定的配置文件。	选择配置文件还未实现。
IllegalArgumentException		证书是空的。	用户名/密码未提交。
Unsupported Media Type		此服务器拒绝服务请求，因为实体请求的格式不受 请求的资源的请求的方法 支持。(翻译水平不足，无法理解请阅读英文原文)	数据未被应用程序提交/json

Authenticate

Authenticates a user using their password.

Endpoint

/authenticate

Payload

{
    "agent": {                              // defaults to Minecraft
        "name": "Minecraft",                // For Mojang's other game Scrolls, "Scrolls" should be used
        "version": 1                        // This number might be increased
                                            // by the vanilla client in the future
    },
    "username": "mojang account name",      // Can be an email address or player name for
                                            // unmigrated accounts
    "password": "mojang account password",
    "clientToken": "client identifier",     // optional
    "requestUser": true                     // optional; default: false; true adds the user object to the response
}

The clientToken should be a randomly generated identifier and must be identical for each request. The vanilla launcher generates a random (version 4) UUID on first run and saves it, reusing it for every subsequent request. In case it is omitted the server will generate a random token based on Java's UUID.toString() which should then be stored by the client. This will however also invalidate all previously acquired accessTokens for this user across all clients.

Response

{
    "accessToken": "random access token",      // hexadecimal
    "clientToken": "client identifier",        // identical to the one received
    "availableProfiles": [                     // only present if the agent field was received
        {
            "id": "profile identifier",        // hexadecimal
            "name": "player name",
            "legacy": true or false            // In practice, this field only appears in the response if true. Default to false.
        }
    ],
    "selectedProfile": {                       // only present if the agent field was received
        "id": "uuid without dashes",
        "name": "player name",
        "legacy": true or false
    },
    "user": {                                  // only present if requestUser was true in the request payload
        "id": "user identifier",               // hexadecimal
        "properties": [
            {
                "name": "preferredLanguage",   // might not be present for all accounts
                "value": "en"                  // ISO 639-1?
            },
            {
                "name": "twitch_access_token", // only present if a twitch account is associated (see https://account.mojang.com/me/settings)
                "value": "twitch oauth token"  // OAuth 2.0 Token; alphanumerical; e.g. https://api.twitch.tv/kraken?oauth_token=[...]
                                               // the Twitch API is documented here: https://github.com/justintv/Twitch-API
            }
        ]
    }
}

Note: If a user wishes to stay logged in on their computer you are strongly advised to store the received accessToken instead of the password itself.

Currently each account will only have one single profile, multiple profiles per account are however planned in the future. If a user attempts to log into a valid Mojang account with no attached Minecraft license, the authentication will be successful, but the response will not contain a selectedProfile field, and the availableProfiles array will be empty.

Some instances in the wild have been observed of Mojang returning a flat null for failed refresh attempts against legacy accounts. It's not clear what the actual error tied to the null response is and it is extremely rare, but implementations should be wary of null output from the response.

This endpoint is severely rate-limited: multiple /authenticate requests for the same account in a short amount of time (think 3 requests in a few seconds), even with the correct password, will eventually lead to an Invalid credentials. response. This error clears up a few seconds later.

Refresh

Refreshes a valid accessToken. It can be used to keep a user logged in between gaming sessions and is preferred over storing the user's password in a file (see lastlogin).

Endpoint

/refresh

Payload

{
    "accessToken": "valid accessToken",
    "clientToken": "client identifier",  // This needs to be identical to the one used
                                         // to obtain the accessToken in the first place
    "selectedProfile": {                 // optional; sending it will result in an error
        "id": "profile identifier",      // hexadecimal
        "name": "player name"
    },
    "requestUser": true                  // optional; default: false; true adds the user object to the response
}

Note: The provided accessToken gets invalidated.

Response

{
    "accessToken": "random access token",      // hexadecimal
    "clientToken": "client identifier",        // identical to the one received
    "selectedProfile": {
        "id": "profile identifier",            // hexadecimal
        "name": "player name"
    },
    "user": {                                  // only present if requestUser was true in the request payload
        "id": "user identifier",               // hexadecimal
        "properties": [
            {
                "name": "preferredLanguage",   // might not be present for all accounts
                "value": "en"                  // ISO 639-1?
            },
            {
                "name": "twitch_access_token", // only present if a twitch account is associated (see https://account.mojang.com/me/settings)
                "value": "twitch oauth token"  // OAuth 2.0 Token; alphanumerical; e.g. https://api.twitch.tv/kraken?oauth_token=[...]
                                               // the Twitch API is documented here: https://github.com/justintv/Twitch-API
            }
        ]
    }
}

Validate

Checks if an accessToken is usable for authentication with a Minecraft server. The Minecraft Launcher (as of version 1.6.13) calls this endpoint on startup to verify that its saved token is still usable, and calls /refresh if this returns an error.

Note that an accessToken may be unusable for authentication with a Minecraft server, but still be good enough for /refresh. This mainly happens when one has used another client (e.g. played Minecraft on another PC with the same account). It seems only the most recently obtained accessToken for a given account can reliably be used for authentication (the next-to-last token also seems to remain valid, but don't rely on it).

/validate may be called with or without a clientToken. If a clientToken is provided, it should match the one used to obtain the accessToken. The Minecraft Launcher does send a clientToken to /validate.

Endpoint

/validate

Payload

{
    "accessToken": "valid accessToken",
    "clientToken": "associated clientToken" // optional, see above
}

Response

Returns an empty payload (204 No Content) if successful, an error JSON with status 403 Forbidden otherwise.

Signout

Invalidates accessTokens using an account's username and password.

Endpoint

/signout

Payload

{
    "username": "mojang account name",
    "password": "mojang account password"
}

Response

Returns an empty payload if successful.

Invalidate

Invalidates accessTokens using a client/access token pair.

Endpoint

/invalidate

Payload

{
    "accessToken": "valid accessToken",
    "clientToken": "client identifier"   // This needs to be identical to the one used
                                         // to obtain the accessToken in the first place
}

Response

Returns an empty payload if successful.

Joining a Server

See Protocol Encryption#Authentication