Each entry in an X authority file corresponds to a particular X display server and is composed of three main components: display-name protocol token
1 – display-name
Identifies the name of the X display to which you are authorizing access. The display name follows the supported display name format: [transport/]host:[:]server[.screen] This format enables you to use a single X authority file to grant varying levels of access to different X display servers and connection families. For example, the following entries grant access to the local display server on node HUBBUB and the remote display server on node ZEPHYR via the DECnet transport: local/HUBBUB:0 MIT-MAGIC-COOKIE-1 cfcc5ef98f9718f90154f355c0ae9f62 decnet/ZEPHYR::0 MIT-MAGIC-COOKIE-1 cfcc5ef98f9718f90154f355c0ae9f62 o [transport/] Identifies the network transport used to connect to an X display server. See the DECwindows Motif documentation for a list of the supported transport values. If a transport value is not specified, the default value is interpreted from the format of the remaining portions of the display-name entry, for example: Host address and one colon (116.94.24.187:0) (TCP/IP) Two colons (::0 or ZEPHYR::0) (DECnet) No host name or address and one colon (:0) (local) o host[:] Identifies the name of the host system where the X display server is located. A value of 0 is interpreted as the local host, which is the default. The type of host is determined by the transport value. See the DECwindows documentation for examples of valid host name and address formats. o :server Identifies the server. This value is required and must be preceded by a single colon (:). Typically the value for a single-server system is :0. If you are specifying a display on a multi-server system (such as when using a proxy server), additional values may apply depending on the number of servers in the configuration. If you have specified a display device (with the SET DISPLAY command), the server portion of the entry is assumed from the device specification. o [.screen] Identifies the screen. On OpenVMS Alpha and OpenVMS I64 systems, the screen value is not held in the X authority file and is ignored when included in a command. All screens on a single server have the same authorization.
2 – protocol
Indicates the authentication protocol in use. Valid values are MIT-MAGIC-COOKIE-1 and MIT-KERBEROS-5.
3 – token
A random alphanumeric string that functions as a password authorizing a server connection. The format of the token depends on the authorization scheme in use. MIT-MAGIC-COOKIE-1 uses a 128-bit string known as a magic cookie. MIT-KERBEROS-5 uses an encrypted string to authorize server connections. This string is stored separately. The token entry in the X authority file represents the encoded location of the Kerberos keytab file and associated principal name, which is referenced by the server to locate the encrypted string.