with reference to fig3 , there is shown a block diagram of a system ( 300 ) in which the preferred embodiment can be implemented . server 1 comprises an authenticator ( 305 ), a generator ( 310 ), an encryptor ( 315 ) and a first transmitter ( 320 ). server 2 comprises a decryptor ( 325 ), an authorizer ( 330 ) and a second transmitter ( 335 ). it should be understood , that preferably , server 1 also comprises a decryptor and server 2 also comprises a generator and an encryptor ; these components , however , have not been shown in fig3 , for clarity . with reference to fig3 and fig4 , an administrator ( 115 ) sends ( step 400 ) a first symmetric key to server 1 and sends ( step 405 ) the first symmetric key to server 2 . preferably , the administrator ( 115 ) sends the keys over a secure channel . a user at a client computer ( 105 ) sends ( step 410 ) their credentials to server 1 to be authenticated . in a first example , the credentials comprise a user id and a password . in response to receiving the credentials , the authenticator ( 305 ) authenticates ( step 415 ) the credentials against an authentication server . in response to an unsuccessful authentication , the process ends . alternatively , a notification can be sent to the administrator ( 115 ). in response to a successful authentication , the generator ( 310 ) generates ( step 415 ) a first token comprising a portion of the credentials . it should be understood that the token can comprise any number of portions of the credentials , such as a user id only , a user id and password , and so forth . it should be understood that the token can comprise other data such as time of expiry of the token . in the first example , the first token comprises the user id . a representation of the first token is shown below : the encryptor ( 315 ) encrypts ( step 415 ) the first token with a second symmetric key . it should be understood that the second symmetric key can be sent to server 1 and server 2 at the same time as sending of the first symmetric key by the administrator ( 115 ) ( i . e . at steps 400 and 405 ). alternatively , the second symmetric key can be generated by server 1 and server 2 using a pre - agreed algorithm which generates the same second symmetric key given a first symmetric key . alternatively , server 1 generates the second symmetric key and the first symmetric key is used to encrypt a token comprising both the user id and the second symmetric key . it should be understood that the second symmetric key ( i . e ., the symmetric key that is used to encrypt a portion of the user &# 39 ; s credentials ) is required to be updated periodically as described above , for example in order to defeat traffic analysis attacks . the generator ( 310 ) also generates ( step 420 ) a second token comprising a third symmetric key , wherein the third symmetric key is the updated symmetric key to the second symmetric key . in a preferred implementation , the third symmetric key is generated on a pre - selected server . in a first example , the third symmetric key is generated on a server from which a user receives a token prior to logging onto other servers . for example , if a user more frequently connects first to server 1 and then to server 2 , and less frequently connects in the reverse order , or if a user must connect to server 1 before connecting to server 2 , then preferably , the third symmetric key is generated on server 1 . this ensures that the third symmetric key is then transmitted efficiently to other servers . it should be understood that a server can be pre - selected based on any number of other aspects e . g . probability of key distribution to all other servers ; timeliness of key distribution ; frequency of key distribution etc . in one embodiment , an administrator pre - selects a server for generating and distributing a symmetric key . alternatively , a selection component ( not shown ) pre - selects a server for generating and distributing a symmetric key . preferably , the selection component analyses selection data in order to select a server . for example , the selection component analyses a list of servers that a user has previously connected to . the list can be stored , for example in the user &# 39 ; s token . in response to the analysis , the selection component selects a server . preferably , data associated with the selected server is added to the second token that is generated in order to transmit the updated symmetric key generated by the selected server . the encryptor ( 315 ) encrypts ( step 420 ) the second token with the first symmetric key received from the administrator ( 115 ). the generator ( 310 ) also generates ( step 425 ) a third token comprising the first token and the second token . a representation of the third token is shown below : & lt ; token — 3 & gt ;& lt ; token — 1 & gt ; encrypted with second symmetric key ( user id )& lt ;/ token — 1 & gt ;; & lt ; token — 2 & gt ; encrypted with first symmetric key ( symmetric_key — 3 )& lt ;/ token — 2 & gt ;& lt ;/ token — 3 & gt ; it should be understood , that the third token can be generated in a number of ways . for example , the third token itself can be encrypted with the second symmetric key . this further step provides an additional layer of protection against traffic analysis attacks aimed at discovering the third symmetric key . the first transmitter ( 320 ) sends ( step 430 ) the third token to the client computer ( 105 ). typically a token is implemented as a cookie ( i . e ., a data block ). when the cookie is sent to a client computer comprising a web browser , the cookie is stored on the client computer in the web browser &# 39 ; s cache memory . the user sends ( step 435 ) a request for a resource , for example an http request for a web page , to server 2 . the request comprises the third token . if the token is a cookie , the cookie is sent with an http request . in another implementation , the token can be included as a parameter included in a header associated with the http request . in another implementation , the token can be included as a parameter in all subsequent http requests through the standard process of url rewriting . because server 1 and server 2 already have the same symmetric key ( i . e ., the first and second symmetric keys ), in response to receiving the third token , the decryptor ( 325 ) decrypts ( step 440 ) the first token using the second symmetric key in order to obtain the user id . the decryptor ( 325 ) also decrypts ( step 445 ) the second token using the first symmetric key received from the administrator ( 115 ) in order to obtain the third symmetric key . in response to an unsuccessful decryption the process ends . alternatively , a notification can be sent to the administrator ( 115 ). in response to a successful decryption at step 440 , the authorizer ( 330 ) uses the client computer identity in the token in order to determine whether the user is authorized to access the resource . in response to a successful authorization , server 2 sends a response ( step 450 ) ( e . g . a http response ) to the client computer ( 105 ). content associated with the resource ( e . g . a web page ) can then be sent from server 2 to the client computer ( 105 ). in response to a successful decryption at step 445 , server 2 obtains the third symmetric key that is the updated symmetric key to the second symmetric key . it should be understood that the third symmetric key can now be used in subsequent communications . it should be understood that the preferred embodiment can be implemented in a number of ways . for example , a client computer authenticates with server 1 . the client computer then receives an updated symmetric key in a token from server 2 . in a subsequent communication , the client computer transmits the token to server 1 . it should be understood that a user can access multiple sso environments . thus , there is a need for an associated client computer to present a token to a server in the correct sso environment . in one example , an sso environment can be defined by a dns domain . thus , a client computer determines a hostname associated with a server and presents a token to a server with a hostname within a given dns domain . in another example , a client computer can maintain and / or access a list of servers within a given sso environment . when a client computer accesses a server , the client computer presents a token comprising an identifier associated with the sso environment for which a token is valid . advantageously , by one server adding an updated symmetric key to the token , the preferred embodiment allows for the updated symmetric key to be transmitted to other servers in the sso environment . the preferred embodiment advantageously utilizes existing communication flows between a user and servers in a sso environment in order to transmit an updated symmetric key between the servers in the sso environment . advantageously , a method of transmitting an updated symmetric key , when a key change is required , is provided which overcomes problems associated with the prior art . that is , manual effort or complex scripts are not required in order to transmit the updated symmetric key . furthermore , network connections between servers are not required in order to transmit the updated symmetric key . furthermore , when a user authenticates with one server , the user is used to securely transmit a token between servers , despite the user being un - trusted ( i . e ., because the user can present any data when presenting a token to other servers ). that is , by using an initial symmetric key ( i . e ., the first symmetric key ) to encrypt data in the second token , a secure method by which an updated symmetric key is transmitted and received is provided . because a user is used by a server to distribute an updated symmetric key , preferably , extra security features are provided . in one such security feature , a pre - selected user or set of users is nominated to transmit an updated symmetric key via a token . the user can be pre - selected based on an authentication threshold , for example wherein it is determined whether the user is authenticated at a particular access level threshold . furthermore , preferably , a user does not receive a symmetric key in clear text form . furthermore , since the second symmetric key can be changed to a third , fourth and later symmetric key , this key is less prone to attack , for example from traffic analysis . furthermore , since typically , the first symmetric key is less regularly used to encrypt data , the first symmetric key is less prone to attacks ( e . g . from traffic analysis ). because a user is used by a server to distribute an updated symmetric key , preferable extra reliability and assurance of distribution features are provided . for example , multiple users can be used to distribute a given symmetric key from server 1 to server 2 , so that there is redundancy in key distribution . for example , a portion of an updated symmetric key is added by a first server to a token that is sent to a first user . the remaining portion of the updated symmetric key is added by the first server to a token that is sent to a second user . thus , when the first user and the second user transmit the portions to a second server , the second server generates the updated symmetric key by utilizing the portions . thus , increased security is provided by splitting the updated symmetric key , because the first user would need to know about ( i . e ., in order to collaborate with ) the second user in order to obtain the remaining portion of the updated symmetric key , or vice versa . furthermore , a third party would need to know about both users in order to obtain the portions of the updated symmetric key . when different subsets of a symmetric key are distributed via different users , it is possible that all of the users may not connect to a second server after first connecting to a first server . thus , preferably , an error correction code is used , which facilitates the entire symmetric key being reconstructed by a second server even if a configurable percentage of users do not later connect to the second server after first receiving their subset of a symmetric key from the first server . preferably , if an updated symmetric key is transmitted to a second server , the second server sends an acknowledgement that it has received the updated symmetric key to a first server . preferably , the first server begins to use the updated symmetric key in subsequent communications only after receiving an acknowledgement of the receipt of the updated symmetric key from a second server in the sso environment . because a user is used by a server to distribute an updated symmetric key , preferably extra coordination features are provided to allow servers to coordinate a time period during which a given symmetric key is valid for use . in one example , a time period is pre - configurable , during which a given symmetric key is valid . thus , the given symmetric key is valid for encrypting a token only within the configured time period . preferably , a token that is presented to a server that has been encrypted by a symmetric key that was valid in a previous time period is rejected and / or an administrator is notified . in one embodiment , the time period is configured by an administrator . in another embodiment , the time period is configured by a server . preferably , data associated with the time period is included in a token ( e . g . a token comprising an updated symmetric key ). in another example , a rolling subset of symmetric keys is valid . for example , until a first server receives an acknowledgement that an updated symmetric key has been received by a second server or if a client computer presents a token to the first server , wherein the token has been generated by the second server and encrypted with the updated symmetric key , a token generated by the second server using a previous symmetric key can be permitted for a grace period . in response to determining that the grace period is nearing expiry , for example by comparison against a time threshold , a notification is sent to the administrator , so that the administrator can perform analysis such as , for example a determination of a cause of the updated symmetric key failing to reach the second server . at the expiration of the grace period , preferably a token encrypted using the previous symmetric key is rejected and / or an administrator is notified . it should be understood , that although the preferred embodiment has been described in relation to symmetric keys , the preferred embodiment can be used with other data such as a shared secret , public / private keys pairs , and the like .