Difference between revisions of "Session"

From wiki.vg
Jump to navigation Jump to search
m (Fixed session ID section)
(Added refresh method + removed sections which were moved to their own pages)
Line 34: Line 34:
 
</syntaxhighlight>
 
</syntaxhighlight>
  
 +
=== Session ID ===
  
=== Session ID ===
 
 
Whenever a Mojang service requires a session ID, you can simply combine a valid <code>accessToken</code> with a profile identifier as follows:
 
Whenever a Mojang service requires a session ID, you can simply combine a valid <code>accessToken</code> with a profile identifier as follows:
  
Line 41: Line 41:
  
 
=== Authenticate ===
 
=== Authenticate ===
 +
 
This method is used whenever a user tries to log in using his password.
 
This method is used whenever a user tries to log in using his password.
  
Line 49: Line 50:
 
<syntaxhighlight lang="javascript">
 
<syntaxhighlight lang="javascript">
 
{
 
{
   "agent": {
+
   "agent": {                             // optional
 
     "name": "Minecraft",                // So far this is the only encountered value
 
     "name": "Minecraft",                // So far this is the only encountered value
 
     "version": 1                        // This number might be increased
 
     "version": 1                        // This number might be increased
Line 61: Line 62:
 
</syntaxhighlight>
 
</syntaxhighlight>
  
The <code>clientToken</code> should be a randomly generated identifier and must identical for each request.
+
The <code>clientToken</code> 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 [http://docs.oracle.com/javase/7/docs/api/java/util/UUID.html#toString() UUID.toString()] which should then be stored by the client.
+
In case it is omitted the server will generate a random token based on Java's [http://docs.oracle.com/javase/7/docs/api/java/util/UUID.html#toString() UUID.toString()] which should then be stored by the client. This will however also invalidate all previously acquired <code>accessToken</code>s for this user across all clients.
 +
 
  
 
==== Response ====
 
==== Response ====
Line 69: Line 71:
 
   "accessToken": "random access token",  // hexadecimal
 
   "accessToken": "random access token",  // hexadecimal
 
   "clientToken": "client identifier",    // identical to the one received
 
   "clientToken": "client identifier",    // identical to the one received
   "availableProfiles": [
+
   "availableProfiles": [                 // only present if the agent field was received
 
     {
 
     {
 
       "id": "profile identifier",        // hexadecimal
 
       "id": "profile identifier",        // hexadecimal
Line 75: Line 77:
 
     }
 
     }
 
   ],
 
   ],
   "selectedProfile": {
+
   "selectedProfile": {                   // only present if the agent field was received
 
     "id": "profile identifier",
 
     "id": "profile identifier",
 
     "name": "player name"
 
     "name": "player name"
Line 85: Line 87:
 
Currently each account will only have one single profile, multiple profiles per account are however planned in the future.
 
Currently each account will only have one single profile, multiple profiles per account are however planned in the future.
  
 +
=== Refresh ===
  
== Updating ==
+
This method is used to refresh an expired but valid <code>accessToken</code>. 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]]).
  
To update, the launcher downloads files from
+
==== Endpoint ====
<pre>http://s3.amazonaws.com/MinecraftDownload/</pre>
+
  /refresh
It takes the unix timestamp from the login request and stores it in ~/.minecraft/bin/version<br />
 
The following files are downloaded from /MinecraftDownload/ in this exact order:<br />
 
*lwjgl.jar
 
*jinput.jar
 
*lwjgl_util.jar
 
*minecraft.jar
 
And then the natives.jar appropriate for the following operating systems: windows, linux, macosx, and solaris
 
*<os-from-list-above>_natives.jar.lzma
 
  
When downloading minecraft.jar, GET variables are set as follows: ?user=foo&ticket=deprecated, although they seem unnecessary to successfully downloading the file. <br />
+
==== Payload ====
Furthermore, the downloaded files are all verified via MD5 which is sent via ETag by the server on the page for each file.
+
<syntaxhighlight lang="javascript">
 +
{
 +
  "accessToken": "valid accessToken",
 +
  "clientToken": "client identifier"    // This needs to be identical to the one used
 +
                                        // to obtain the accessToken in the first place
 +
}
 +
</syntaxhighlight>
  
Further resources are stored in /MinecraftResources. Loading /MinecraftResources provides an XML formatted list of resources, some of which are downloaded by Minecraft and not the launcher.
+
Note: The provided <code>accessToken</code> gets invalidated.
  
=== Updating 1.6 ===
+
==== Response ====
 
+
<syntaxhighlight lang="javascript">
With the new launcher updating happens by downloading information from https://s3.amazonaws.com/Minecraft.Download/versions/versions.json and https://s3.amazonaws.com/Minecraft.Download/versions/1.6.2/1.6.2.json
+
{
 
+
  "accessToken": "random access token", // hexadecimal
 
+
  "clientToken": "client identifier",    // identical to the one received
== Snoop ==
+
  "selectedProfile": {
 
+
    "id": "profile identifier",         // hexadecimal
Every 15 minutes, minecraft sends a HTTP POST request giving stats. This can be disabled in server.properties
+
    "name": "player name"
 
+
  }
* '''client''': http://snoop.minecraft.net/client?version=1
+
}
* '''server''': http://snoop.minecraft.net/server?version=1
+
</syntaxhighlight>
  
{| class="wikitable"
 
|- class="row0"
 
! Field
 
!style="width: 72px" | Client
 
!style="width: 72px" | Server
 
! Example
 
! Notes
 
|-
 
| applet
 
| {{yes}}
 
| {{no}}
 
| <code>true</code>
 
|
 
|-
 
| avg_rec_packet_count
 
| {{no}}
 
| {{yes}}
 
| <code>0</code>
 
|
 
|-
 
| avg_rec_packet_size
 
| {{no}}
 
| {{yes}}
 
| <code>0</code>
 
|
 
|-
 
| avg_sent_packet_count
 
| {{no}}
 
| {{yes}}
 
| <code>6</code>
 
|
 
|-
 
| avg_sent_packet_size
 
| {{no}}
 
| {{yes}}
 
| <code>44</code>
 
|
 
|-
 
| avg_tick_ms
 
| {{no}}
 
| {{yes}}
 
| <code>3</code>
 
|
 
|-
 
| client_brand
 
| {{yes}}
 
| {{no}}
 
| <code>vanilla</code>
 
| via <code>ClientBrandRetriever.getClientModName()</code>
 
|-
 
| cpu_cores
 
| {{yes}}
 
| {{yes}}
 
| <code>2</code>
 
| via <code>Runtime.getRuntime().availableProcessors()</code>
 
|-
 
| dedicated
 
| {{no}}
 
| {{yes}}
 
| <code>true</code>
 
|
 
|-
 
| display_frequency
 
| {{yes}}
 
| {{no}}
 
| <code>60</code>
 
| via <code>org.lwjgl.opengl.Display.getDisplayMode().getFrequency()</code>
 
|-
 
| display_type
 
| {{yes}}
 
| {{no}}
 
| <code>windowed</code>
 
| <code>windowed</code> or <code>fullscreen</code>
 
|-
 
| fps
 
| {{yes}}
 
| {{no}}
 
| <code>60</code>
 
|
 
|-
 
| gl_caps[''key'']
 
| {{yes}}
 
| {{no}}
 
| ''varies by key''
 
| via <code>org.lwjgl.opengl.GLContext.getCapabilities().GL_ARB_''key''</code>
 
|-
 
| gl_max_texture_size
 
| {{yes}}
 
| {{no}}
 
| <code>8192</code>
 
|
 
|-
 
| gui_state
 
| {{no}}
 
| {{yes}}
 
| <code>disabled</code>
 
| <code>enabled</code> or <code>disabled</code>
 
|-
 
| gui_supported
 
| {{no}}
 
| {{yes}}
 
| <code>headless</code>
 
| via <code>java.awt.GraphicsEnvironment.isHeadless()</code> (<code>headless</code> or <code>supported</code>)
 
|-
 
| java_version
 
| {{yes}}
 
| {{yes}}
 
| <code>1.6.0_24</code>
 
| via <code>System.getProperty("java.version")</code>
 
|-
 
| jvm_arg[''n'']
 
| {{yes}}
 
| {{yes}}
 
| <code>-Xms2800M</code>
 
| via <code>java.lang.management.ManagementFactory.getRuntimeMXBean().getInputArguments()</code> (-X args only)
 
|-
 
| jvm_args
 
| {{yes}}
 
| {{yes}}
 
| <code>2</code>
 
| see above
 
|-
 
| memory_free
 
| {{yes}}
 
| {{yes}}
 
| <code>2429082024</code>
 
| via <code>Runtime.getRuntime().freeMemory()</code>
 
|-
 
| memory_max
 
| {{yes}}
 
| {{yes}}
 
| <code>2813722624</code>
 
| via <code>Runtime.getRuntime().maxMemory()</code>
 
|-
 
| memory_total
 
| {{yes}}
 
| {{yes}}
 
| <code>2813722624</code>
 
| via <code>Runtime.getRuntime().totalMemory()</code>
 
|-
 
| opengl_vendor
 
| {{yes}}
 
| {{no}}
 
| <code>NVIDIA Corporation</code>
 
| via <code>GL11.glGetString(GL_VENDOR)</code>
 
|-
 
| opengl_version
 
| {{yes}}
 
| {{no}}
 
| <code>3.3.0 NVIDIA 302.17</code>
 
| via <code>GL11.glGetString(GL_VERSION)</code>
 
|-
 
| os_architecture
 
| {{yes}}
 
| {{yes}}
 
| <code>amd64</code>
 
| via <code>System.getProperty("os.arch")</code>
 
|-
 
| os_name
 
| {{yes}}
 
| {{yes}}
 
| <code>Linux</code>
 
| via <code>System.getProperty("os.name")</code>
 
|-
 
| os_version
 
| {{yes}}
 
| {{yes}}
 
| <code>3.2.0-3-amd64</code>
 
| via <code>System.getProperty("os.version")</code>
 
|-
 
| players_current
 
| {{no}}
 
| {{yes}}
 
| <code>0</code>
 
|
 
|-
 
| players_max
 
| {{no}}
 
| {{yes}}
 
| <code>20</code>
 
|
 
|-
 
| players_seen
 
| {{no}}
 
| {{yes}}
 
| <code>4</code>
 
| counts files in world/players
 
|-
 
| server_brand
 
| {{no}}
 
| {{yes}}
 
| <code>vanilla</code>
 
| via <code>getServerModName()</code> (hardcoded to "vanilla", overwritten by bukkit et al)
 
|-
 
| singleplayer
 
| {{no}}
 
| {{yes}}
 
| <code>false</code>
 
| whether or not the server is running to support a singleplayer session
 
|-
 
| snooper_count
 
| {{yes}}
 
| {{yes}}
 
| <code>0</code>
 
| how many times the snooper has reported so far
 
|-
 
| snooper_token
 
| {{yes}}
 
| {{yes}}
 
| <code>dfe921ac-0293-4e42-8d99-1316cdd626d8</code>
 
| via <code>java.util.UUID.randomUUID().toString()</code> (unique per program launch)
 
|-
 
| texpack_name
 
| {{yes}}
 
| {{no}}
 
| <code>Default</code>
 
|
 
|-
 
| texpack_resolution
 
| {{yes}}
 
| {{no}}
 
| <code>16</code>
 
|
 
|-
 
| uses_auth
 
| {{no}}
 
| {{yes}}
 
| <code>true</code>
 
| corresponds to <code>online-mode</code> in server.properties
 
|-
 
| version
 
| {{yes}}
 
| {{yes}}
 
| <code>1.4.2</code>
 
|
 
|-
 
| vsync_enabled
 
| {{yes}}
 
| {{no}}
 
| <code>true</code>
 
|
 
|-
 
| whitelist_count
 
| {{no}}
 
| {{yes}}
 
| <code>0</code>
 
|
 
|-
 
| whitelist_enabled
 
| {{no}}
 
| {{yes}}
 
| <code>false</code>
 
|
 
|-
 
| world[''n''][chunks_loaded]
 
| {{no}}
 
| {{yes}}
 
| <code>978</code>
 
|
 
|-
 
| world[''n''][difficulty]
 
| {{no}}
 
| {{yes}}
 
| <code>1</code>
 
|
 
|-
 
| world[''n''][dimension]
 
| {{no}}
 
| {{yes}}
 
| <code>0</code>
 
|
 
|-
 
| world[''n''][generator_name]
 
| {{no}}
 
| {{yes}}
 
| <code>default</code>
 
|
 
|-
 
| world[''n''][generator_version]
 
| {{no}}
 
| {{yes}}
 
| <code>1</code>
 
|
 
|-
 
| world[''n''][hardcore]
 
| {{no}}
 
| {{yes}}
 
| <code>false</code>
 
|
 
|-
 
| world[''n''][height]
 
| {{no}}
 
| {{yes}}
 
| <code>256</code>
 
|
 
|-
 
| world[''n''][mode]
 
| {{no}}
 
| {{yes}}
 
| <code>SURVIVAL</code>
 
|
 
|-
 
| worlds
 
| {{no}}
 
| {{yes}}
 
| <code>3</code>
 
|}
 
  
 
== Joining a Server ==
 
== Joining a Server ==

Revision as of 16:21, 15 July 2013

The minecraft client and server communicate with minecraft.net to validate player sessions. This page describes some of the operations.

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:

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

Session ID

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

 token:<accessToken>:<profile ID>

Authenticate

This method is used whenever a user tries to log in 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.

Refresh

This method is used to refresh an expired but 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
}

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


Joining a Server

See Protocol Encryption for details on encrypting connections.

Client operation

  1. Client connects to server
  2. Client sends a 0x02 handshake containing the current player name
  3. Client receives an 0xFD encryption request with the server's public key and four verification bytes.
  4. Client generates a symmetric key.
  5. Client sends a HTTP request to
    http://session.minecraft.net/game/joinserver.jsp?user=<player name>&sessionId=<session id>&serverId=<server hash>
    Note: See the Session ID section on how the <session id> is generated.
    If the response is OK then continue, otherwise stop
  6. Client sends 0xFC encryption response - client encrypts shared secret and verification token with the server's public key
  7. Server checks validity and sends 0xFC encryption response with two empty arrays
  8. Both sides enable AES/CFB2 encryption using the shared secret generated by the client
  9. Client sends 0xCD client status with a payload of 0 (ready to spawn)
  10. Server sends 0x01 login
  11. ... receive map chunks, etc...

Server operation

  1. Server generates a 1024-bit RSA keypair.
  2. ...
  3. Server answers TCP connection request and receives a 0x02 handshake from the client.
  4. Server sends 0xFD encryption request with its public key and a verification token.
  5. Server receives 0xFC encryption response from client and decrypts the shared secret.
  6. Server verifies the validity of the verification token. If this isn't verified, it kicks the client.
  7. Server sends a HTTP request to
    http://session.minecraft.net/game/checkserver.jsp?user=<username>&serverId=<server hash>
    If it returns YES then the client is authenticated and allowed to join. Otherwise the client will/should be kicked with “Failed to verify username!”
  8. Server sends a 0xFC encryption response packet with two empty arrays.
  9. Both sides enable AES/CFB2 encryption.
  10. Server receives 0xCD client status with a payload of , indicating "ready to spawn"
  11. Server sends 0x01 login
  12. ... send map chunks, etc...


Outdated authentication system

This system was used by Minecraft versions prior to 1.6 and might be discontinued at any moment without warning.

Login

To log the player in, the official launcher sends an HTTPS POST (GET appears to suffice as well) request to:

https://login.minecraft.net

with the postdata:

 ?user=<username>&password=<password>&version=<launcher version>

and a "application/x-www-form-urlencoded" Content-Type header.

After migrating to Mojang accounts, email address is used instead of username, but the procedure stays the same.

The current launcher version is "13" (for new launcher it's "14"), sending a value lower than 12 will cause the server to return "Old version", however you can send any large number and it will return as expected. If the login succeeded, it will return 5 ':' delimited values.

 1343825972000:deprecated:SirCmpwn:7ae9007b9909de05ea58e94199a33b30c310c69c:dba0c48e1c584963b9e93a038a66bb98
  1. current version of the game files (not the launcher itself). This is a unix timestamp which the launcher compares to the ~/.minecraft/bin/version file.
  2. Previously contained a download ticket for requesting new versions of minecraft.jar from the server. Now contains only "deprecated".
  3. case-correct username. For mojang accounts, the user's actual username is returned here instead of the email used to log in.
  4. sessionId - a unique ID for your current session.
  5. UID - currently unused, introduced near August 8th, 2012. Grum says this is the unique ID for the user, potentially for changing Minecraft names in future.

If the request is missing a parameter, the server will return "Bad response". If the login information is incorrect, the server will return "Bad login". If the login information is correct but the account isn't premium, the server will return "User not premium". If your minecraft.net account has been migrated to a Mojang account but you're logging in with your minecraft.net username the server will return "Acount migrated, use e-mail".

Keep-alive

Every 6000 ticks, the client sends an HTTPS request to

https://login.minecraft.net/session?name=<username>&session=<session id>

The client discards the server's response.