Legacy Mojang Authentication

Minecraft 1.6 introduced a new authentication scheme called Yggdrasil which completely replaces the previous authentication system.

Request format

All requests to Yggdrasil are made to the following server:

 https://authserver.mojang.com

Further, they are expected to fulfill the following rules:

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

If a request was successful the server will respond with:

• Status code 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
• A JSON-encoded dictionary following this format:

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

Errors

These are some of the errors that can be encountered:

Error	Cause	Error message	Notes
Method Not Allowed		The method specified in the request is not allowed for the resource identified by the request URI	Something other than a POST request was received.
Not Found		The server has not found anything matching the request URI	Non-existing endpoint was called.
ForbiddenOperationException	UserMigratedException	Invalid credentials. Account migrated, use e-mail as username.
ForbiddenOperationException		Invalid credentials. Invalid username or password.
ForbiddenOperationException		Invalid token.	accessToken was invalid.
IllegalArgumentException		Access token already has a profile assigned.	Selecting profiles isn't implemented yet.
Unsupported Media Type		The server is refusing to service the request because the entity of the request is in a format not supported by the requested resource for the requested method	Data was not submitted as application/json

Session ID

Whenever a Mojang service requires a session ID, you can simply combine a valid accessToken with the corresponding profile identifier as follows:

 token:<accessToken>:<profile ID>

Authenticate

Authenticates a user using his password.

Endpoint

 /authenticate

Payload

{
  "agent": {                             // optional
    "name": "Minecraft",                 // So far this is the only encountered value
    "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
}

The clientToken should be a randomly generated identifier and must be identical for each 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"
    }
  ],
  "selectedProfile": {                   // only present if the agent field was received
    "id": "profile identifier",
    "name": "player name"
  }
}

Note: If a user wishes to stay logged in on his 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.

Refresh

Refreshes a valid accessToken. It can be uses 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"
  }
}

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

Validate

Checks if an accessToken is valid.

Endpoint

 /validate

Payload

{
  "accessToken": "valid accessToken",
}

Response

Returns an empty payload if successful.

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