共管账户的授权方法和装置、共管账户的认证方法和装置与流程

本申请涉及网络通信技术领域，尤其涉及一种共管账户的授权方法和装置、以及一种共管账户的认证方法和装置。

背景技术：

共管账户是由两个或两个以上的共管人共同管理的账户，共管人可以是自然人，也可以是法人。共管账户适用于共管人因各种原因需要共同支配同一账户，但出于对安全或信任的考虑，不能由单个共管人掌握这个账户所有权限(如转账、体现)的情况。

由于共管账户的一些权限需要所有共管人同意后方能行使，提供共管账户服务的银行等机构通常要求所有共管人同时去到柜台来办理需认证权限的业务，使得操作共管账户极其不便。而现有技术中，各种可以通过网络操作的账户都只有一个所有者，当认证该所有者具有操作权限后，即可对电子账户进行各种操作；换言之，现有技术中并不支持多个所有者通过网络共同管理一个账户的应用场景。

技术实现要素：

有鉴于此，本申请提供一种共管账户的授权方法，应用在客户端，所述共管账户由n个共管人共同管理，n为大于1的自然数，所述方法包括：

获取共管账户的用户侧认证参数；所述用户侧认证参数与所述共管账户的网络侧认证参数相同或相对应，用于对所述共管账户的操作权限进行认证；

将用户侧认证参数拆分为n个部分，根据每个部分生成对应的共管认证 参数，将每个共管认证参数分别写入由每个共管人控制的设备中。

本申请提供的一种共管账户的授权方法，应用在服务端，所述共管账户由n个共管人共同管理，n为大于1的自然数，所述方法包括：

获取共管账户的用户侧认证参数和网络侧认证参数，保存网络侧认证参数；所述用户侧认证参数与网络侧认证参数相同或相对应，用于对所述共管账户的操作权限进行认证；

将用户侧认证参数拆分为n个部分，根据每个部分生成对应的共管认证参数，将每个共管认证参数分别下发给不同共管人的客户端。

本申请提供的一种共管账户的授权方法，应用在共同账户共管人的客户端，所述共管账户由n个共管人共同管理，n为大于1的自然数，所述方法包括：

接收服务端下发的共管认证参数；所述共管认证参数由服务端将用户侧认证参数拆分为n个部分后，根据其中一个部分生成；所述用户侧认证参数用于对所述共管账户的操作权限进行认证；

保存所述共管认证参数。

本申请提供的一种共管账户的认证方法，应用在客户端，所述共管账户由n个共管人共同管理，n为大于1的自然数，所述方法包括：

获取共管账户的n个共管认证参数；

根据每个共管认证参数还原用户侧认证参数的一个部分，将n个部分组合为用户侧认证参数；

采用所述用户侧认证参数向服务端发起认证请求，供服务端根据网络侧认证参数对所述共管账户的操作权限进行认证；所述网络侧认证参数与用户侧认证参数相同或相对应。

本申请提供的一种共管账户的认证方法，应用在服务端，所述共管账户由n个共管人共同管理，n为大于1的自然数，所述方法包括：

接收客户端上传的n个共管认证参数；

根据每个共管认证参数还原用户侧认证参数的一个部分，将n个部分组 合为用户侧认证参数；

根据网络侧认证参数对所述共管账户的操作权限进行认证；所述网络侧认证参数与用户侧认证参数相同或相对应。

本申请提供的一种共管账户的认证方法，应用在客户端，所述共管账户由n个共管人共同管理，n为大于1的自然数，所述方法包括：

获取属于某个共管人的共管认证参数；

将所述共管认证参数上传到服务端，供服务端根据所述共管认证参数还原出用户侧认证参数的一个部分，并与其它(n-1)个部分组合为用户侧认证参数后，采用与所述用户侧认证参数相同或相对应的网络侧认证参数来对所述共管账户的操作权限进行认证。

本申请还提供了一种共管账户的授权装置，应用在客户端，所述共管账户由n个共管人共同管理，n为大于1的自然数，所述装置包括：

用户侧参数获取单元，用于获取共管账户的用户侧认证参数；所述用户侧认证参数与所述共管账户的网络侧认证参数相同或相对应，用于对所述共管账户的操作权限进行认证；

共管参数写入单元，用于将用户侧认证参数拆分为n个部分，根据每个部分生成对应的共管认证参数，将每个共管认证参数分别写入由每个共管人控制的设备中。

本申请提供的一种共管账户的授权装置，应用在服务端，所述共管账户由n个共管人共同管理，n为大于1的自然数，所述装置包括：

认证参数获取单元，用于获取共管账户的用户侧认证参数和网络侧认证参数，保存网络侧认证参数；所述用户侧认证参数与网络侧认证参数相同或相对应，用于对所述共管账户的操作权限进行认证；

共管参数下发单元，用于将用户侧认证参数拆分为n个部分，根据每个部分生成对应的共管认证参数，将每个共管认证参数分别下发给不同共管人的客户端。

本申请提供的一种共管账户的授权装置，应用在共同账户共管人的客户 端，所述共管账户由n个共管人共同管理，n为大于1的自然数，所述装置包括：

共管参数接收单元，用于接收服务端下发的共管认证参数；所述共管认证参数由服务端将用户侧认证参数拆分为n个部分后，根据其中一个部分生成；所述用户侧认证参数用于对所述共管账户的操作权限进行认证的生成；

共管参数保存单元，用于保存所述共管认证参数。

本申请提供的一种共管账户的认证装置，应用在客户端，所述共管账户由n个共管人共同管理，n为大于1的自然数，所述装置包括：

共管参数获取单元，用于获取共管账户的n个共管认证参数；

用户侧参数组合单元，用于根据每个共管认证参数还原用户侧认证参数的一个部分，将n个部分组合为用户侧认证参数；

认证请求发起单元，用于采用所述用户侧认证参数向服务端发起认证请求，供服务端根据网络侧认证参数对所述共管账户的操作权限进行认证；所述网络侧认证参数与用户侧认证参数相同或相对应。

本申请提供的一种共管账户的认证装置，应用在服务端，所述共管账户由n个共管人共同管理，n为大于1的自然数，所述装置包括：

共管参数接收单元，用于接收客户端上传的n个共管认证参数；

用户侧参数组合单元，用于根据每个共管认证参数还原用户侧认证参数的一个部分，将n个部分组合为用户侧认证参数；

操作权限认证单元，用于根据网络侧认证参数对所述共管账户的操作权限进行认证；所述网络侧认证参数与用户侧认证参数相同或相对应。

本申请提供的一种共管账户的认证装置，应用在客户端，所述共管账户由n个共管人共同管理，n为大于1的自然数，所述装置包括：

单个共管参数获取单元，用于获取属于某个共管人的共管认证参数；

共管参数上传单元，用于将所述共管认证参数上传到服务端，供服务端根据所述共管认证参数还原出用户侧认证参数的一个部分，并与其它(n-1)个部分组合为用户侧认证参数后，采用与所述用户侧认证参数相同或相对应 的网络侧认证参数来对所述共管账户的操作权限进行认证。

由以上技术方案可见，本申请的实施例中，将用于对共管账户操作权限认证的用户侧认证参数拆分为n个部分，根据每个部分生成对应的共管认证参数并交由一个共管人控制，使得共管人可以用通过网络提供各自的共管认证参数来对行使对共管账户的操作权限，从而实现了基于网络的共管账户，极大的方便了共管人的管理操作；

本申请的实施例中，在对共管账户的操作权限进行认证时，由n个共管人提供各自控制的共管认证参数，利用n个共管认证参数组合出用户侧认证参数后由服务端进行权限认证，使得共管人可以用通过网络提供各自的共管认证参数来对行使对共管账户的操作权限，实现了基于网络的共管账户，为共管账户的管理提供了极大的便利。

附图说明

图1是本申请实施例一中一种应用在客户端，共管账户的授权方法的流程图；

图2是本申请实施例一中一种应用场景的网络结构示意图；

图3是本申请实施例二中一种应用在服务端，共管账户的授权方法的流程图；

图4是本申请实施例二中一种应用在客户端，共管账户的授权方法的流程图；

图5是本申请实施例二中一种应用场景的网络结构示意图；

图6是本申请实施例三中一种应用在客户端，共管账户的认证方法的流程图；

图7是本申请实施例四中一种应用在客户端，共管账户的认证方法的流程图；

图8是本申请实施例四中一种应用在服务端，共管账户的认证方法的流程图；

图9是客户端或服务端所在设备的一种硬件结构图；

图10是本申请实施例五中一种应用在客户端，共管账户的授权装置的逻辑结构图；

图11是本申请实施例六中一种应用在服务端，共管账户的授权装置的逻辑结构图；

图12是本申请实施例六中一种应用在客户端，共管账户的授权装置的逻辑结构图；

图13是本申请实施例七中一种应用在客户端，共管账户的授权装置的逻辑结构图；

图14是本申请实施例八中一种应用在服务端，共管账户的授权装置的逻辑结构图；

图15是本申请实施例八中一种应用在客户端，共管账户的授权装置的逻辑结构图。

具体实施方式

本申请的实施例提出一种新的共管账户的授权方法和一种新的共管账户的认证方法，对由n(n为大于1的自然数)个共管人共同管理的共管账户，将用户侧认证参数拆分为n个部分后，根据每个部分生成一个共管认证参数，n个共管认证参数分别由n个共管人控制；在进行操作权限认证时，只有每个共管人都提供各自的共管认证参数，在组合为用户侧认证参数后才能由服务端认证通过，从而使得共管人可以通过网络实现对共有账户的管理，为共管人提供了更多的便利。

本申请的实施例中，用户侧认证参数和网络侧认证参数相同或相对应，用来对共管账户的操作权限进行认证。用户侧认证参数由用户保管，网络侧认证参数保存在服务端，服务端利用网络侧认证参数对客户端提供的用户侧认证参数或客户端采用用户侧认证参数发起的操作请求进行鉴权，在通过认证后用户才能对其账户进行所请求的操作。由于本申请中用户侧认证参数由 n个共管人共同持有，为了确保每个共管人的权益，应尽量避免某个或部分共管人了解或持有完整的用户侧认证参数，因此本申请的实施例中用户侧认证参数和网络侧认证参数通常由客户端或服务端自动生成，而一般不采用人工设置的方式。

本申请的实施例中，客户端运行在用户侧设备上，客户端可以是由一个共管人所有的设备，也可以是由n个共管人共同使用的设备；服务端运行在共管账户的服务提供方设备上。客户端所在设备和服务端所在设备通过网络相互可访问。客户端所在设备可以是手机、平板电脑、pc(personalcomputer，个人电脑)、笔记本、服务器等设备；服务端所在设备可以是pc、笔记本、服务器等设备。其中，服务器可以是一个物理或逻辑服务器，也可以是由两个或两个以上分担不同职责的物理或逻辑服务器、相互协同来实现本申请实施例中的各项功能。本申请实施例对客户端和服务端所在设备的种类，以及相互间通信网络的类型、协议等均不做限定。

本申请的实施例一中描述一种共管账户的授权方法，由客户端负责根据用户侧网络参数生成并向各个共管人分发共管认证参数，该方法应用在客户端的流程如图1所示。

在客户端，步骤110，获取共管账户的用户侧认证参数。

如前所述，用户侧认证参数和网络侧认证参数通常自动生成。例如，客户端可以采用某种算法生成相同或相对应的用户侧认证参数和网络侧认证参数，并且将生成的网络侧认证参数上传到服务端，供服务端在认证过程中使用。再如，也可以由服务端采用某种算法生成相同或相对应的用户侧认证参数和网络侧认证参数，保存网络侧认证参数，将用户侧认证参数发送给客户端。

客户端或服务端可以参照现有技术中各种密钥、口令的生成算法来生成用户侧认证参数和网络侧认证参数，例如，客户端采用非对称加密算法生成私钥和公钥，以私钥作为用户侧认证参数，以公钥作为网络侧认证参数。再如，服务端采用对称加密算法生成相同的密钥，同时作为用户侧认证参数和 网络侧认证参数。

在客户端，步骤120，将用户侧认证参数拆分为n个部分，根据每个部分生成对应的共管认证参数，将每个共管认证参数分别写入由每个共管人控制的设备中。

客户端将用户侧认证参数拆分为n个部分，这n个部分相互间不包含，并且可以组合为完整的用户侧认证参数。客户端分别采用每个部分，生成对应的共管认证参数。

具体的用户侧认证参数拆分方式可以根据实际应用场景、生成共管认证参数的算法等因素来确定，本申请的实施例中不做限定。例如，可以将用户侧认证参数拆分为n个分段，以分段序号表示该分段在用户侧认证参数中的排序(以便在将各个分段组合为用户侧认证参数时，能够以正确的顺序排列所有分段)，把每个分段及其分段序号作为共管认证参数。再如，可以将用户侧认证参数拆分为2n个分段，以第k个分段、第(k+n)个分段和k(k为从1到n的自然数)作为某个映射算法的输入并进行加密后得到对应的共管认证参数，并且该映射算法的逆算法能够以共管认证参数解密后的值为输入，输出与该共管认证参数对应的第k个分段、第(k+n)个分段和k。

客户端将生成的n个共管认证参数分别写入由每个共管人控制的设备中，供该共管人在授权对共管账户的操作时使用。其中，写入共管认证参数的设备可以是共管人的客户端所在的设备，也可以是与共管人客户端所在设备可分离的存储介质。

需要说明的是，本实施例中，运行共管账户的授权方法的客户端可以是n个共管人客户端中的一个，也可以是非n个共管人的客户端。如果共管认证参数是由某个共管人客户端分发给其他客户端，则客户端的实现应确保分发给其他共管人的(n-1)个共管认证参数不会留存在生成这些参数的客户端上。

在一种实现方式中，非n个共管人的客户端(例如可以是开始共管账户的服务机构的客户端)将所生成的n个共管认证参数分别写入属于每个共管 人的nfc(nearfieldcommunication，近场通信)芯片中，其应用场景的网络结构如图2所示。由于nfc芯片支持非接触式读取，在nfc芯片中保存共管认证参数使用起来更为便捷。

本申请的实施例二中描述一种共管账户的授权方法，由服务端负责根据用户侧网络参数生成并向各个共管人分发共管认证参数，该方法应用在服务端的流程如图3所示，应用在客户端的流程如图4所示。

在服务端，步骤310，获取共管账户的用户侧认证参数和网络侧认证参数，保存网络侧认证参数。

服务端可以采用某种算法生成相同或相对应的用户侧认证参数和网络侧认证参数，也可以从网络中提供密钥或口令生成服务的其他服务器那里获取相同或相对应的用户侧认证参数和网络侧认证参数。

服务端可以参照现有技术中各种密钥、口令的生成算法来生成用户侧认证参数和网络侧认证参数。例如，服务端可以采用对称加密算法生成相同的密钥，同时作为用户侧认证参数和网络侧认证参数。

服务端将所获取的网络侧认证参数保存在本地，或网络中可访问的存储位置。

在服务端，步骤320，将用户侧认证参数拆分为n个部分，根据每个部分生成对应的共管认证参数，将每个共管认证参数分别下发给不同共管人的客户端。

服务端拆分用户侧认证参数、生成共管认证参数的详细说明请参见实施例一中对客户端完成相同功能的描述，不再重复。在一种实现方式中，可以将用户侧认证参数分为n个分段，以每个分段及其分段序号作为一个共管认证参数。

服务端将生成的n个共管认证参数分别下发给不同共管人的客户端，其应用场景的一种网络结构如图5所示。

在客户端，步骤410，接收服务端下发的共管认证参数。

对某一个共管人的客户端，服务端下发的共管认证参数由服务端将用户 侧认证参数拆分为n个部分后，根据其中一个部分生成。在一种实现方式中，共管认证参数包括用户侧认证参数的n个分段中的其中一个分段，以及该分段的分段序号。

在客户端，步骤420，保存接收的共管认证参数。

客户端可以将接收的共管认证参数保存在客户端所在的设备本地；也可以保存在能够与客户端所在设备分离的存储介质中，如nfc芯片、usb(universalserialbus，通用串行总线)闪存盘等。

可见，本申请的实施例一和实施例二中，将用户侧网络参数拆分为n个部分后以每个部分生成一个共管认证参数，n个共管认证参数分别由n个共管人控制，在每个共管人提供各自的共管认证参数后才能行使对共管账户的操作权限。本申请的上述两个实施例实现了基于网络的共管账户，为共管人的账户操作提供了更大便利。

本申请的实施例三中描述一种共管账户的认证方法，由客户端负责根据n个共管认证参数生成用户侧网络参数，该方法应用在客户端的流程如图6所示。

步骤610，获取共管账户的n个共管认证参数。

共管账户的n个共管人人每人控制一个共管认证参数。当n个共管人均同意对共管账户进行某项需认证权限的操作后，可以由每个共管人将其控制的共管认证参数提供给运行本实施例共管账户认证方法的客户端。

如果共管人将其控制的共管认证参数保存在该共管人客户端所在的设备中，则本实施例中运行共管账户认证方法的客户端可以从n个共管人的客户端所在设备读取n个共管认证参数、或者接收n个共管人的客户端发送的共管认证参数。如果共管人将其控制的共管认证参数保存在其所有的存储介质(如属于每个共有人的nfc芯片、或u盘等存储介质)中，则运行共管账户认证方法的客户端可以从这些存储介质中读取n个共管认证参数。

需要说明的是，本实施例中，运行共管账户认证方法的客户端可以是某个共管人的客户端，也可以是非共管人的客户端。当运行共管账户认证方法 的客户端是某个共管人的客户端并且该共管人的共管认证参数保存在客户端所在设备本地时，客户端只要从本地读取保存的这个共管认证参数即可。

步骤620，根据每个共管认证参数还原用户侧认证参数的一个部分，将n个部分组合为用户侧认证参数。

客户端在获得n个共管认证参数后，按照生成共管认证参数时所采用的方式，逆向从每个共管认证参数还原出对应的用户侧认证参数的一个部分(即用来生成该共管认证参数的部分)，将n个部分组合后，即可得到用户侧认证参数。

以前述将用户侧认证参数的n个分段及其分段序号作为n个共管认证参数的应用场景为例，则可以从每个共管认证参数解析出用户侧认证参数的一个分段及该分段的分段序号，按照每个分段的分段序号，将n个分段顺序衔接后生成用户侧认证参数。

步骤630，采用用户侧认证参数向服务端发起认证请求，供服务端根据网络侧认证参数对共管账户的操作权限进行认证。

根据实际应用场景中客户端与服务端之间权限认证的具体实现方式，采用用户侧认证参数发起认证请求的形式可能有所不同。例如，客户端可以在认证请求中携带用户侧认证参数，服务端将认证请求中的用户侧认证参数与其保存的网络侧认证参数进行比对，如果相同或相对应，则该认证请求通过，该客户端可以对共管账户进行所请求的操作；否则拒绝该客户端的请求。

再如，当用户侧认证参数和网络侧认证参数分别是非对称加密算法的私钥和公钥时，客户端可以采用私钥(即用户侧认证参数)对认证请求、或认证请求中的某个或某些字段进行数字签名，并将带有数字签名的认证请求发送给服务端；服务端采用该认证请求操作对象的共管账户的公钥(即网络侧认证参数)对该认证请求进行验签，如果通过则允许该客户端对该共管账户进行所请求的操作，否则拒绝该客户端的请求。

本申请的实施例四中描述一种共管账户的认证方法，由服务端负责根据n个共管认证参数生成用户侧网络参数，该方法应用在服务端的流程如图7 所示，应用在客户端的流程如图8所示。

在客户端，步骤810，获取属于某个共管人的共管认证参数。

根据共管认证参数的保存位置，客户端可以从所在设备本地读取共管认证参数、或接收保存共管认证参数的客户端发送的共管认证参数；也可以从属于某个共管人的存储介质中读取共管认证参数。

在客户端，步骤820，将共管认证参数上传到服务端，供服务端根据共管认证参数还原出用户侧认证参数的一个部分，并与其它(n-1)个部分组合为用户侧认证参数后，采用与该用户侧认证参数相同或相对应的网络侧认证参数来对该共管账户的操作权限进行认证。

在服务端，步骤710，接收客户端上传的n个共管认证参数。

根据实际应用场景的不同，客户端可以采用多种方式将共管认证参数上传给服务器，本实施例中的客户端和服务端可以支持某一种方式，也可以同时支持多种方式。以下举出四个例子，来具体说明。

在第一个例子中，当所有共管人协商同意对共管账户进行某项操作后，每个共管人指令其客户端获取该共管人的共管认证参数后，在共管账户操作请求中发送给服务端。客户端还可以在共管账户操作请求中携带对共管账户的操作内容，告知服务端本请求要授权进行的操作是什么。

在第二个例子中，某个共管人可以从通过其客户端向其他共管人的客户端发送共管账户授权请求，在其中携带对共管账户的操作内容。同意进行该操作的每个共管人(包括向其他共管人发起授权请求的共管人)的客户端分别向服务端发送共管账户操作请求，其中包括该共管人的共管认证参数(还可以包括操作内容)。

在第三个例子中，某个共管人向服务端发送共管账户操作请求，在其中携带所请求的操作内容。服务端收到共管账户操作请求后，向该共管账户的每个共管人客户端发送共管认证参数上传请求，在其中携带发起操作请求的共管人要进行的操作内容。客户端收到共管账户操作请求后，如果该共管人同意进行该项操作，则将其共管认证参数在对共管账户操作请求的响应中回 复给服务端。

在第四个例子中，某个共管人向服务端发送共管账户操作请求，在其中携带所请求的操作内容和该共管人的共管认证参数。服务端收到共管账户操作请求后，向该共管账户的每个其他共管人(除发起操作请求的共管人之外的其他共管人)客户端发送共管认证参数上传请求，在其中携带发起操作请求的共管人要进行的操作内容。其他共管人的客户端收到共管账户操作请求后，如果该共管人同意进行该项操作，则将其共管认证参数在对共管账户操作请求的响应中回复给服务端。

上述各个例子中，当所有共管人同意对共管账户进行所请求的操作时，服务端将从n个共管人的客户端分别收到其上传的n个共管认证参数。

在服务端，步骤720，根据每个共管认证参数还原用户侧认证参数的一个部分，将n个部分组合为用户侧认证参数。

服务端在获得n个共管认证参数后，按照生成共管认证参数时所采用的方式，逆向从每个共管认证参数还原出对应的用户侧认证参数的一个部分(即用来生成该共管认证参数的部分)，将n个部分组合后，即可得到用户侧认证参数。

以前述将用户侧认证参数的n个分段及其分段序号作为n个共管认证参数的应用场景为例，则可以从每个共管认证参数解析出用户侧认证参数的一个分段及该分段的分段序号，按照每个分段的分段序号，将n个分段顺序衔接后生成用户侧认证参数。

在服务端，步骤730，根据网络侧认证参数对该共管账户的操作权限进行认证。

在生成用户侧认证参数后，服务端将其保存的网络侧认证参数与用户侧认证参数进行匹配，如果两者相同或者相对应，则认证通过，允许客户端对该共管账户进行所请求的操作，否则拒绝客户端对共管账户的操作请求。

可见，本申请的实施例三和实施例四中，在n个共管人分别通过客户端向服务端提供其控制的共管认证参数后，服务端由n个共管认证参数得到用 户侧认证参数，采用网络侧认证参数对共管账户的操作权限进行认证。共管人可以通过网络提供各自的共管认证参数来对行使对共管账户的操作权限，实现了基于网络的共管账户，方便了共管人的操作。

本申请一个应用示例的组网结构如图2所示，其中，客户端所在的设备是带有nfc功能的移动终端，共管账户共有三个共管人(n＝3)，每个共管人各自拥有一个nfc标签。

在对共管账户的操作权限进行授权时，带有nfc功能的移动终端采用rsa算法(一种非对称加密算法)，生成共管账户的一对rsa公钥和私钥。公钥由移动终端上传给服务端，保存为该共管账户的网络侧认证参数。移动终端将私钥拆分为3个分段，并为每个分段生成分段序号；移动终端以每个分段及其分段序号作为一个共管人的共管认证参数，通过nfc读卡器模式写入到该共管人的nfc标签中。3个写入不同共管认证参数的nfc标签分别由3个共管人持有。

在希望对共管账户进行需要权限认证的操作时，3个共管人分别提供各自持有的nfc标签，由带有nfc功能的移动终端通过nfc读卡器模式读出3个nfc标签中存储的3个共管认证参数。移动终端从每个共管认证参数中解析出私钥的一个分段和该分段的分段序号，按照分段序号将3个分段衔接起来，组合成该共管账户的私钥。移动终端采用用户侧认证参数对任意数据做数字签名，上传至服务端。服务端将使用该共管账户的公钥验签所提交数据，从而判断是否认证通过。在认证通过后，移动终端即可对该共管账户进行操作。

与上述流程实现对应，本申请的实施例还提供了两种应用在客户端的共管账户授权装置、一种应用在服务端的共管账户授权装置、两种应用在客户端的共管账户认证装置和一种应用在服务端的共管账户认证装置。这些装置均可以通过软件实现，也可以通过硬件或者软硬件结合的方式实现。以软件实现为例，作为逻辑意义上的装置，是通过客户端或服务端所在设备的cpu(centralprocessunit，中央处理器)将对应的计算机程序指令读取到内存中 运行形成的。从硬件层面而言，除了图9所示的cpu、内存以及非易失性存储器之外，客户端或服务端所在设备通常还包括用于进行无线信号收发的芯片等其他硬件，和/或用于实现网络通信功能的板卡等其他硬件。

图10所示为本申请实施例五提供的一种共管账户的授权装置，应用在客户端，所述共管账户由n个共管人共同管理，n为大于1的自然数，所述装置包括用户侧参数获取单元和共管参数写入单元，其中：用户侧参数获取单元用于获取共管账户的用户侧认证参数；所述用户侧认证参数与所述共管账户的网络侧认证参数相同或相对应，用于对所述共管账户的操作权限进行认证；共管参数写入单元用于将用户侧认证参数拆分为n个部分，根据每个部分生成对应的共管认证参数，将每个共管认证参数分别写入由每个共管人控制的设备中。

一个例子中，所述用户侧参数获取单元具体用于：生成共管账户的用户侧认证参数和网络侧认证参数，将网络侧认证参数上传给服务端。

上述例子中，所述用户侧认证参数和网络侧认证参数可以包括：非对称加密算法的私钥和公钥。

可选的，所述用户侧参数获取单元具体用于：从服务端接收由服务端生成的用户侧认证参数。

可选的，所述共管参数写入单元具体用于：将用户侧认证参数分为n个分段，以每个分段及其分段序号作为一个共管认证参数，将每个共管认证参数分别写入由每个共管人控制的设备中。

可选的，所述由每个共管人控制的设备包括：属于每个共管人的近场通信nfc芯片。

图11所示为本申请实施例六提供的一种共管账户的授权装置，应用在服务端，所述共管账户由n个共管人共同管理，n为大于1的自然数，所述装置包括认证参数获取单元和共管参数下发单元，其中：认证参数获取单元用于获取共管账户的用户侧认证参数和网络侧认证参数，保存网络侧认证参数；所述用户侧认证参数与网络侧认证参数相同或相对应，用于对所述共管账户 的操作权限进行认证；共管参数下发单元用于将用户侧认证参数拆分为n个部分，根据每个部分生成对应的共管认证参数，将每个共管认证参数分别下发给不同共管人的客户端。

可选的，所述共管参数下发单元具体用于：将用户侧认证参数分为n个分段，以每个分段及其分段序号作为一个共管认证参数，将每个共管认证参数分别下发给不同共管人的客户端。

可选的，所述认证参数获取单元具体用于：根据预定算法生成对称密钥或口令，同时用作用户侧认证参数和网络侧认证参数。

图12所示为本申请实施例六提供的一种共管账户的授权装置，应用在共同账户共管人的客户端，所述共管账户由n个共管人共同管理，n为大于1的自然数，所述装置包括共管参数接收单元和共管参数接收单元，其中：共管参数接收单元用于接收服务端下发的共管认证参数；所述共管认证参数由服务端将用户侧认证参数拆分为n个部分后，根据其中一个部分生成；所述用户侧认证参数用于对所述共管账户的操作权限进行认证的生成；共管参数保存单元用于保存所述共管认证参数。

可选的，所述共管认证参数包括：所述用户侧认证参数的n个分段中的其中一个分段及其分段序号。

可选的，所述共管参数保存单元具体用于：将所述共管认证参数保存在客户端所在设备，或保存在可与客户端所在设备分离的存储介质中。

图13所示为本申请实施例七提供的一种共管账户的认证装置，应用在客户端，所述共管账户由n个共管人共同管理，n为大于1的自然数，所述装置包括共管参数获取单元、用户侧参数组合单元和认证请求发起单元，其中：共管参数获取单元用于获取共管账户的n个共管认证参数；用户侧参数组合单元用于根据每个共管认证参数还原用户侧认证参数的一个部分，将n个部分组合为用户侧认证参数；认证请求发起单元用于采用所述用户侧认证参数向服务端发起认证请求，供服务端根据网络侧认证参数对所述共管账户的操作权限进行认证；所述网络侧认证参数与用户侧认证参数相同或相对应。

一个例子中，所述共管参数获取单元具体用于：从n个共管人的客户端所在设备获取共管账户的n个共管认证参数；或者从分别属于n个共管人的存储介质读取共管账户的n个共管认证参数。

上述例子中，所述分别属于n个共管人的存储介质，包括：属于每个共管人的近场通信nfc芯片。

可选的，所述用户侧参数组合单元具体用于：根据每个共管认证参数还原出用户侧认证参数的一个分段及其分段序号，将n个分段按照其分段序号衔接为用户侧认证参数。

可选的，所述用户侧认证参数和网络侧认证参数包括：非对称加密算法的私钥和公钥；所述认证请求发起单元具体用于：以所述私钥对向服务端发起的认证请求进行数字签名，供服务端采用所述公钥对所述认证请求进行验签。

图14所示为本申请实施例八提供的一种共管账户的认证装置，应用在服务端，所述共管账户由n个共管人共同管理，n为大于1的自然数，所述装置包括共管参数接收单元、用户侧参数组合单元和操作权限认证单元，其中：共管参数接收单元用于接收客户端上传的n个共管认证参数；用户侧参数组合单元用于根据每个共管认证参数还原用户侧认证参数的一个部分，将n个部分组合为用户侧认证参数；操作权限认证单元用于根据网络侧认证参数对所述共管账户的操作权限进行认证；所述网络侧认证参数与用户侧认证参数相同或相对应。

可选的，所述用户侧参数组合单元具体用于：根据每个共管认证参数还原用户侧认证参数的一个分段及其分段序号，将n个分段按照其分段序号衔接为用户侧认证参数。

可选的，所述共管参数接收单元具体用于：接收n个共管人的客户端分别上传的n个共管认证参数。

可选的，所述装置还包括操作请求接收单元和参数上传请求发送单元，其中：操作请求接收单元用于接收某个共管人客户端发送的共管账户操作请 求，其中包括操作内容；参数上传请求发送单元用于向其他(n-1)个共管人的客户端发送共管认证参数上传请求，其中包括所述操作内容。

图15所示为本申请实施例八提供的一种共管账户的认证装置，应用在客户端，所述共管账户由n个共管人共同管理，n为大于1的自然数，所述装置包括单个共管参数获取单元和共管参数上传单元，其中：单个共管参数获取单元用于获取属于某个共管人的共管认证参数；共管参数上传单元用于将所述共管认证参数上传到服务端，供服务端根据所述共管认证参数还原出用户侧认证参数的一个部分，并与其它(n-1)个部分组合为用户侧认证参数后，采用与所述用户侧认证参数相同或相对应的网络侧认证参数来对所述共管账户的操作权限进行认证。

可选的，所述单个共管参数获取单元具体用于：从某个共管人的客户端所在设备获取所述共管认证参数；或者从属于某个共管人的存储介质读取所述共管认证参数。

可选的，所述装置还包括操作请求发送单元，用于向服务端发送共管账户操作请求，其中包括操作内容。

可选的，所述装置还包括参数上传请求接收单元，用于接收服务端发送的共管认证参数上传请求，其中包括某个共管人发起的共管账户操作请求中的操作内容；所述共管参数上传单元具体用于：在对所述共管认证参数上传请求的响应中，将共管认证参数上传到服务端。

以上所述仅为本申请的较佳实施例而已，并不用以限制本申请，凡在本申请的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本申请保护的范围之内。

在一个典型的配置中，计算设备包括一个或多个处理器(cpu)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(ram)和/或非易失性内存等形式，如只读存储器(rom)或闪存(flashram)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(pram)、静态随机存取存储器(sram)、动态随机存取存储器(dram)、其他类型的随机存取存储器(ram)、只读存储器(rom)、电可擦除可编程只读存储器(eeprom)、快闪记忆体或其他内存技术、只读光盘只读存储器(cd-rom)、数字多功能光盘(dvd)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitorymedia)，如调制的数据信号和载波。

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。

本领域技术人员应明白，本申请的实施例可提供为方法、系统或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、cd-rom、光学存储器等)上实施的计算机程序产品的形式。