Protocol, IP)地址，也可以为该外部服务器的IP地址对应的域名。
[0051] 沿用上例，即时通讯服务器接收到终端发送的外部登录请求后，获取该外部登录 请求中携带的即时通讯账号和支付服务器（外部服务器）的IP地址（服务器标识）。
[0052] S103、内部服务器向该服务器标识对应的外部服务器发送该内部账号，以使该外 部服务器查找与该内部账号预先绑定的外部账号，并登录该外部账号。
[0053] 继续沿用上例，即时通讯服务器通过步骤S102获取到用户当前登录的即时通讯 账号和支付服务器的IP地址后，根据该IP地址，向支付服务器发送该即时通讯账号。
[0054] S104、外部服务器接收内部服务器发送的内部账号。
[0055] S105、外部服务器查找与该内部账号预先绑定的外部账号。
[0056] 在本申请实施例中，外部服务器中保存有如表1所示的多个外部账号与内部账号 的绑定关系。
[0058] 表1
[0059] 由表1可知，外部账号208801与内部账号1980001绑定；外部账号208802与内部 账号1980002绑定。假设外部服务器接收到内部服务器发送的内部账号为1980001，则外部 服务器在表1中查找与内部账号1980001绑定的外部账号208801。
[0060] 在本申请实施例中，以绑定内部账号1980001与外部账号208801为例说明。其中， 内部账号1980001对应的用户名为A，登录密码为11，外部账号208801对应的用户名为B， 登录密码为22。
[0061] 具体的，用户首先在外部服务器提供的外部账号登录页面上输入外部账号对应的 用户名B和登录密码22,登录该外部账号208801，然后进入外部账号中的账号绑定页面，在 该页面的提示下，输入与内部账号对应的用户名A和登录密码11。外部服务器将该用户名 A和登录密码11发送给内部服务器，内部服务器接收到该用户名A和登录密码11之后，验 证该用户名A和登录密码11正确，并将用户名A对应的内部账号1980001发送给外部服务 器。外部服务器确定并保存内部账号1980001与外部账号208801的绑定关系。
[0062] 上述内部账号与外部账号是在外部服务器上绑定的，当然，内部账号与外部账号 也可以在内部服务器上绑定，并将该内部账号与外部账号的绑定关系保存在内部服务器 中。具体绑定过程与上述内部账号与外部账号的绑定过程类似，这里不再赘述。
[0063] S106、外部服务器登录该外部账号。
[0064] 例如，当支付服务器通过步骤S105查找到该支付账号（外部账号）为208801后， 支付服务器可自动登录该支付账号208801。
[0065] 本申请实施例提供的如图1所示的方法，外部服务器根据内部服务器提供的内部 账号，查找自身存储的与该内部账号绑定的外部账号，并自动登录该外部账号，由于本申请 提供的外部账号不是保存在终端本地的cookie数据中，也不是通过登录页面输入的，而是 保存在外部服务器中的，并由该外部服务器自动登录该外部账号，因此，就避免了 cookie 数据中保存的外部账号安全性较低的问题，以及避免了在登录页面上输入外部账号不安全 的问题，从而可保证该外部账号的安全性。另外，在本申请实施例中，外部服务器查找到外 部账号之后，可自动登录该外部账号，而不需要用户进行账号、密码等的相关操作，从而可 有效提高用户登录外部账号的便利性。
[0066] 在上述步骤S103中，内部服务器向外部服务器发送内部账号之前，还需要确定该 外部服务器是合法的，这是因为，如果内部服务器将内部账号发送给非法的外部服务器，就 无法保证该内部账号的安全性。
[0067] 因此，在本申请实施例中，内部服务器向外部服务器发送内部账号之前，可向外部 服务器发送令牌，并验证外部服务器返回的该令牌的签名，根据对签名的验证结果来确定 该外部服务器是否合法。
[0068] 具体的，内部服务器通过步骤S103向所述服务器标识对应的外部服务器发送所 述内部账号之前，还包括：
[0069] 内部服务器生成令牌，并将该令牌发送给外部服务器，外部服务器接收该内部服 务器发送的令牌，对该令牌进行签名，并将该签名返回给内部服务器，内部服务器接收该外 部服务器返回的令牌的签名，验证该签名是否合法。当验证结果为该签名合法时，说明该外 部服务合法，则通过步骤S103向外部服务器发送内部账号；当验证结果为该签名非法时， 说明该外部服务器非法，因此，不向该外部服务器发送内部账号。
[0070] 进一步的，当内部服务器验证外部服务器返回的令牌的签名非法时，内部服务器 还可向终端返回提示信息，以提示用户外部服务器不安全。
[0071] 可选的，本申请实施例所述的令牌可以是内部服务器动态生成的随机字符串，该 随机字符串可以为唯一的随机字符串。
[0072] 其中，在本申请实施例中，内部服务器可通过公钥验证外部服务器返回的令牌的 签名是否合法，来确定外部服务器是否合法。具体的，外部服务器接收到令牌之后，使用私 钥对该令牌进行签名，并将该签名返回内部服务器，内部服务器使用公钥验证外部服务器 返回的签名合法，也就确定该外部服务器合法。
[0073] 这是因为，一个公钥对应一个私钥，该私钥仅由合法的内部服务器拥有，即非法的 外部服务器没有该私钥。如果非法的外部服务器采用与该公钥不对应的私钥对令牌进行 签名，并将该签名发送给内部服务器，则内部服务器通过公钥验证该签名时，验证结果为非 法，也就确定返回签名的外部服务器不合法。
[0074] 在实际应用中，外部服务器可预先在内部服务器中注册，可在注册过程中将公钥 保存在该内部服务器中。此外，在该注册过程中，还可将外部服务器的开发者信息保存在内 部服务器中。
[0075] 例如，支付服务器（外部服务器）可预先在即时通讯服务器（内部服务器）中注 册，将公钥保存在即时通讯服务器中，自身保存该私钥。支付服务器还可将邮箱地址、联系 电话、联系地址等开发者信息保存在即时通讯服务器中。
[0076] 上述本申请实施例提供的在确定外部服务器是否合法的过程中，内部服务器生成 的令牌是由该内部服务器发送给外部服务器的，当然，在本申请实施例中，该令牌也可由终 端发送给外部服务器。
[0077] 具体的，内部服务器生成令牌，并将该令牌发送给终端上的APP，该APP接收到令 牌之后，通过该APP中的内置浏览器向外部服务器发送令牌和内部服务器的服务器标识。 外部服务器接收到该APP发送的令牌和内部服务器的服务器标识后，对该令牌进行签名， 并根据接收到的内部服务器的服务器标识将该签名返回给内部服务器。内部服务器接收该 外部服务器返回的令牌的签名后，验证该签名是否合法。当验证结果为该签名合法时，说明 该外部服务器合法，则通过步骤S103向外部服务器发送内部账号；当验证结果为该签名非 法时，说明该外部服务器非法，因此，不向该外部服务器发送内部账号。
[0078] 在本申请实施例中，如果通过终端将令牌发送给外部服务器，则在步骤SlOl中， 终端向内部服务器发送的外部登录请求中可以仅携带内部账号，而不需要携带外部服务器 的服务器标识。
[0079] 在本申请实施例中，当外部服务器通过步骤S105未查找到与该内部账号预先绑 定的外部账号时，还包括：
[0080] 外部服务器创建外部账号，将接收到的内部账号与该创建的外部账号进行绑定， 并登录该创建的外部账号。
[0081] 需要说明的是，外部服务器创建外部账号之后，登录该外部账号与绑定内部账号/ 外部账号之间的先后顺序不限。
[0082] 在实际应用中，终端上可能安装有不止一个APP，且有可能存在不同的APP对应相 同的内部账号，如果仅仅将这些APP的内部账号与对应的外部账号绑定，当外部服务器接 收到内部服务器发送的其中一个APP对应的内部账号时，由于与该内部账号绑定的外部账 号不止一个