一种对业务系统授权的方法及装置与流程

本发明涉及互联网通信领域，特别涉及一种对业务系统授权的方法及装置。

背景技术：

公众社交网络实体是商家在社交平台中注册的账号，商家可以通过公众社交网络实体向用户推广业务。用户可以通过该公众社交网络实体请求商家为其提供业务，商家在用户请求业务时需要社交平台授权其使用用户的用户标识，该用户标识用于在该公众社交网络实体中标识该用户，然后根据该公众用户标识为用户提供业务。

目前商家可以通过如下方式请求社交平台授权其使用用户的用户标识，包括：商家将其业务部署在业务系统中，用户可以通过商家的公众社交网络实体向业务系统发送业务请求；业务系统在接收到该业务请求后，向社交平台发送该公众社交网络实体和其自身的域名；社交平台验证与该公众社交网络实体绑定的域名是否与该域名相同，如果相同，则获取用户的公众用户标识，并发送给业务系统，如此实现向业务系统授权使用用户的用户标识。

其中，商家可能有多个业务系统，但是在社交平台中商家的公众社交网络实体只能与一个域名绑定；这样为了使社交平台验证成功，每个业务系统向社交平台发送自身的域名必须相同，也就是说每个业务系统的域名都相同。

在实现本发明的过程中，发明人发现现有技术至少存在以下问题：

当某个业务系统出现异常时，商家根据该业务系统的域名向该业务系统发送命令，该命令可以用于修复该业务系统或暂停该业务系统；但由于每个业务系统都用同一个域名，这样该命令就发送到商家的每个业务系统，使得每个业务系统都做暂停和修复操作，无法将异常的业务系统与其他业务系统分开处理，不利于容灾隔离。

技术实现要素：

为了增加业务系统的容灾隔离性，本发明提供了一种对业务系统授权的方法及装置。所述技术方案如下：

一方面，提供了一种对业务系统授权的方法，应用于包括至少一个业务系统、授权网关和社交平台的架构，在所述社交平台中所述授权网关的第一域名和公众社交网络实体绑定，所述方法包括：

所述授权网关接收业务系统在用户请求业务时发送的链接请求，所述链接请求携带所述业务系统的第二域名，不同业务系统对应不同的域名；

根据所述链接请求获取所述社交平台对所述授权网关的第一域名和公众社交网络实体验证通过后发送的所述用户的公众用户标识，所述公众用户标识用于在所述公众社交网络实体中标识所述用户；

根据所述第二域名向所述业务系统发送所述公众用户标识。

另一方面，提供了一种对业务系统授权的方法，所述方法包括：

接收用户的社交应用客户端发送的业务请求；

根据所述业务请求向授权网关发送链接请求，所述链接请求携带业务系统的第一域名，所述链接请求用于所述授权网关获取所述用户的公众用户标识，所述公众用户标识是社交平台对所述授权网关的第二域名和公众社交网络实体验证通过后发送的，所述公众用户标识用于在所述公众社交网络实体中标识所述用户；

接收所述授权网关根据所述第一域名发送的所述公众用户标识。

另一方面，一种对业务系统授权的装置，应用于包括至少一个业务系统、所述装置和社交平台的架构，在所述社交平台中所述装置的第一域名和公众社交网络实体绑定，所述装置包括：

接收模块，用于接收业务系统在用户请求业务时发送的链接请求，所述链接请求携带所述业务系统的第二域名，不同业务系统对应不同的域名；

获取模块，用于根据所述链接请求获取所述社交平台对所述装置的第一域名和公众社交网络实体验证通过后发送的所述用户的公众用户标识，所述公众用户标识用于在所述公众社交网络实体中标识所述用户；

发送模块，用于根据所述第二域名向所述业务系统发送所述公众用户标识。

另一方面，提供了一种对业务系统授权的装置，所述装置包括：

接收模块，用于接收用户的社交应用客户端发送的业务请求；

发送模块，用于根据所述业务请求向授权网关发送链接请求，所述链接请求携带业务系统的第一域名，所述链接请求用于所述授权网关获取所述用户的公众用户标识，所述公众用户标识是社交平台对所述授权网关的第二域名和公众社交网络实体验证通过后发送的，所述公众用户标识用于在所述公众社交网络实体中标识所述用户；

所述接收模块，还用于接收所述授权网关根据所述第一域名发送的所述公众用户标识。

本发明提供的技术方案的有益效果是：

通过在接收到业务系统发送的链接请求后，使用授权网关的公众社交网络实体和第二域名代替业务系统向社交平台请求获取用户的公众用户标识；这样无需业务系统的域名与该公众社交网络实体绑定，当商家有多个业务系统时该多个业务系统的域名可以不同，商家可以根据各业务系统的域名分别对各业务系统进行管理和维护，增加业务系统的容灾隔离性。

附图说明

图1是本发明实施例一提供的网络架构示意图；

图2-1是本发明实施例二提供的一种对业务系统授权的方法流程图；

图2-2是本发明实施例二提供的一种授权页面示意图；

图3是本发明实施例三提供的一种对业务授权的方法流程图；

图4是本发明实施例四提供的一种对业务系统授权的装置结构示意图；

图5是本发明实施例五提供的一种对业务系统授权的装置结构示意图；

图6是本发明实施例六提供的一种对业务系统授权的装置结构示意图。

具体实施方式

为使本发明的目的、技术方案和优点更加清楚，下面将结合附图对本发明实施方式作进一步地详细描述。

实施例一

参见图1，本发明实施例提供了一种网络架构，包括：

社交应用客户端1、业务系统2、授权网关3和社交平台4，社交平台4包括社交授权系统41和社交API(Application Programming Interface，应用程序编程接口)系统42。

业务系统2和授权网关3可以是商家部署的，商家可以部署一个或多个业务系统2，分别用于运行不同业务。每个业务系统2都有各自的域名，可以通过商家的公众社交网络实体向用户的社交应用客户端1推广自身运行的业务。

授权网关3也有一个域名，且其域名事先在社交授权系统41中与该公众社交网络实体绑定。当用户通过社交应用客户端1向业务系统2请求业务时，授权网关3可以根据其域名，代替业务系统2请求社交授权系统41和社交API系统42授权用户的公众用户标识和/或用户信息供该业务系统2使用。

对于上述公众社交网络实体，一个用户或组织可以建立一个公众社交网络实体，使任何一个用户不需要经过双方协议同意就可以和这公众社交网络实体进行通信，如接收推送的信息

上述网络架构可以应用于在公众社交网络实体中h5下单或支付的场景中。

实施例二

参见图2-1，本发明实施例提供了一种对业务系统授权的方法，该方法可以应用于实施例一提供的网络架构，包括：

步骤201：社交应用客户端向业务系统发送业务请求，该业务请求携带业务标识。

用户可以在社交应用客户端上打开业务系统对应的公众社交网络实体的应用界面，该应用界面中包括商家在该业务系统中部署的各业务的业务标识。用户可以在该应用界面选择自己需要请求的业务的业务标识。该业务标识可以为业务名称等。

社交应用客户端当检测到用户选择的业务的业务标识时，向业务系统发送业务请求，且该业务请求携带用户选择的该业务的业务标识。

步骤202：业务系统接收该业务请求，根据该业务请求携带的业务标识确定授权方式，向授权网关发送链接请求，该链接请求携带业务系统的第二域名和该授权方式。

业务系统中的业务包括注册业务和非注册业务。

如果用户请求的业务为注册业务，表明用户需要在业务系统中注册。对于用户使用公众社交网络实体请求注册业务的情况，业务系统通常使用用户在社交授权系统上事先注册的公众用户标识和用户信息来完成注册。所以在执行注册业务时，业务系统需要社交授权系统授权其使用用户的公众用户标识和用户信息。该公众用户标识用于在该业务系统对应的公众社交网络实体下标识该用户，用户信息包括用户昵称、用户年龄和用户头像等信息。

如果用户请求的业务为非注册业务，业务系统在接收到该业务请求时需要先根据用户的公众用户标识确定该用户是否已注册，在已注册的情况下向用户提供非注册业务。所以在执行非注册业务时，业务系统需要社交授权系统授权其使用用户的公众用户标识。

本步骤可以为：业务系统接收该业务请求，确定该业务请求携带的业务标识对应的业务；如果该业务为注册业务，则确定授权方式为第一授权方式，第一授权方式用于请求社交授权系统授权业务系统使用用户的公众用户标识和用户信息；如果该业务为非注册业务，则确定授权方式为第二授权方式，第二授权方式用于请求社交授权系统授权业务系统使用用户的公众用户标识；然后向授权网关发送链接请求，该链接请求携带业务系统的第二域名和确定的该授权方式。

步骤203：授权网关接收该链接请求，根据该链接请求向社交应用客户端发送第一消息，第一消息包括该授权方式、授权网关的公众社交网络实体和第一域名。

授权网关和业务系统同属于一个商家，授权网关和业务系统都包括相同的公众社交网络实体，但业务系统的第二域名和授权网关的第一域名可以不同，授权网关还事先在社交授权系统中绑定了第一域名和该公众社交网络实体。

第一消息还可以包括业务系统的第二域名。第一消息的消息形式可以为一个链接消息，该链接消息的域名为第一域名，而第二域名、授权方式和该公众社交网络实体均为该链接消息的参数。

例如，假设第二域名为http://a.example.com，第一域名为http://example.com，该公众社交网络实体为123456以及该授权方式为第一种授权方式，且第一种方式用snsapi_userinfo来表示，所以授权网关生成的链接信息为http://example.com/auth？rurl＝http://a.example/&appid＝123456&scope＝snsapi_userinfo。

参见图2-1，在本步骤中，授权网关接收该链接请求后，根据该链接请求生成第一消息，然后先向业务系统发送第一消息，业务系统接收该第一消息，再向社交应用客户端发送该第一消息。

步骤204：社交应用客户端接收第一消息，根据第一消息向社交授权系统发送授权请求，该授权请求携带该授权方式、该公众社交网络实体、第一域名和用户的社交账号。

用户的社交账号用于在社交授权系统中标识用户，是用户事先通过社交应用客户端在社交授权系统中注册的账号。社交应用客户端中包括用户的社交账号，所以社交应用客户端在发送授权请求前可以获取其包括的用户的社交账号并携带在授权请求中。

当第一消息包括第二域名，该授权请求也可以携带第二域名。该授权请求也可以为一个链接消息，该链接消息在第一消息的基础上增加了一个参数，该参数为用户的社交账号。例如，假设用户的社交账号为78910，所以社交应用客户端发送的授权请求可以为http://example/auth？rurl＝http://a.example.com/&appid＝123456&scope＝snsapi_userinfo&userid＝78910。

步骤205：社交授权系统接收该授权请求，验证与该授权请求携带的公众社交网络实体绑定的域名是否与第一域名相同，如果相同，则验证通过并执行步骤206。

社交授权系统包括公众社交网络实体与域名的对应关系，商家在社交授权系统中申请公众社交网络实体时将其授权网关的域名和申请的公众社交网络实体绑定并存储在该对应关系中。这样为了保证安全，在商家请求授权使用用户的公众用户标识和/或用户信息时，社交授权系统需要验证商家的合法性。

本步骤可以为：社交授权系统接收该授权请求，根据该授权请求携带的公众社交网络实体，从公众社交网络实体与域名的对应关系中获取对应的域名，比较获取的域名与该授权请求携带的第一域名，如果比较出两者相同，则验证通过，如果比较出两者不同，则验证不通过。

在验证不通过时，社交授权系统还可以向社交应用客户端发送通知消息，以通知用户授权失败。例如，在验证不通过时，社交授权系统向社交应用客户端发送通知消息为“域名出错”，社交应用客户端接收该通知消息并可以向用户显示该通知消息。

在本步骤中，由于授权请求是链接消息的形式，第一域名作为该链接消息的域名，而第二域名、公众社交网络实体等其他信息作为该链接消息的参数，因此社交授权系统在接收该链接消息后只会使用身份为域名的第一域名进行验证操作，而不会使用身份为参数的第二域名进行验证操作，从而保证能够成功验证。

步骤206：社交授权系统在该授权方式为第一种授权方式时，请求用户确认是否授权业务系统使用用户信息，如果用户确认授权，则执行步骤207。

由于第一种授权方式用于请求社交授权系统授权业务系统使用用户的公众用户标识和用户信息，又由于用户信息都是用户的隐私信息，涉及到用户的隐私，所以在授权给业务系统使用时，需要以让用户决定是否允许业务系统使用。

在该授权方式为第二种授权方式时，由于第二种授权方式用于请求社交授权系统授权业务系统使用用户的公众用户标识，而不需要用户的用户信息，不会涉及到用户的隐私，因此不需要让用户确认。所以在该授权方式为第二种授权方式时，社交授权系统可以不执行本步骤，而直接跳到步骤207开始执行。

本步骤可以通过如下2061至2063的步骤来实现，包括：

2061：社交授权系统在该授权方式为第一种授权方式时，生成授权页面，并向社交应用客户端发送该授权页面。

授权页面中包括该公众社交网络实体、用户的社交账号和请求授权的用户信息的类型。通过授权页面通知用户业务系统请求授权使用哪些用户信息，以让用户决定是否允许业务系统使用。

例如，参见图2-2所示的社交授权系统生成的授权页面，该授权页面的内容包括“该公众社交网络实体123456”，“业务系统请求授权使用：用户的社交账号78910、用户昵称和用户头等用户信息”。这样在社交应用客户端显示该授权页面时用户便可知道业务系统请求授权哪些信息。

2062：社交应用客户端接收并显示该授权页面，在接收到确定命令时向社交授权系统发送用户确认授权消息。

参见图2-2，该授权页面包括确认按钮和取消按钮，如果用户允许业务系统使用请求授权的用户信息，则点击确认按钮，以使确认按钮产生确认命令，并使社交应用客户端接收该确认命令；如果用户拒绝业务系统使用请求授权的用户信息，则点击取消按钮，以使取消按钮产生取消命令，并结束操作。

2063：社交授权系统接收用户确认授权消息，根据该用户确认授权消息，确定用户确认授权，并执行步骤207。

步骤207：社交授权系统生成票据信息并绑定该票据信息和该用户的社交账号。

社交授权系统绑定该票据信息和该用户的社交账号的操作可以为：将该票据信息和该用户的社交账号存储在票据信息与社交账号的对应关系中，以实现绑定该票据信息和该用户的社交账号。

步骤208：社交授权系统向社交应用客户端发送第三消息，该第三消息包括该票据信息和第一域名。

在接收的授权请求携带第二域名时，该第三消息也可以包括第二域名。该第三消息的消息形式也可以为链接信息，该链接信息的域名仍为第一域名，该票据信息和第二域名作为该链接信息的参数。例如，假设该票据信息为CODE，则该链接信息可以为http://example.com/auth？rurl＝http://a.example.com/&code＝CODE。

步骤209：社交应用客户端接收该第三消息，根据该第三消息包括的第一域名向授权网关发送链接消息，该链接消息包括该票据信息。

在该第三消息包括第二域名时，该链接消息也可以包括第二域名。

步骤210：授权网关接收该链接消息，根据该链接消息向社交API系统发送信息请求，该信息请求携带该票据信息、该公众社交网络实体和密钥信息。

该密钥信息可以是商家在社交授权系统中申请该公众社交网络实体时为该公众社交网络实体设置的登录密码。且在社交API系统中保存有该公众社交网络实体与该密钥信息之间的对应关系。

步骤211：社交API系统接收该信息请求，获取用户的公众用户标识。

在用户使用社交应用客户端首次与商家的公众社交网络实体产生交互(关注、收听、授权)时，社交API系统就自动为用户分配公众用户标识，该公众用户标识用于在该公众社交网络实体下标识该用户；再将该公众社交网络实体、该用户的社交账号和该用户的公众用户标识存储在公众社交网络实体、社交账号与公众用户标识的对应关系中。

本步骤可以为：社交API系统接收该信息请求，根据该信息请求携带的该公众社交网络实体，从公众社交网络实体与密钥信息的对应关系查找对应的密钥信息，如果获取的密钥信息与该信息请求携带的密钥信息相同，则验证通过，并根据该信息请求携带的该票据信息，从社交授权系统中存储的票据信息与社交账号的对应关系中获取用户的社交账号，根据该该公众社交网络实体和用户的社交账号，从公众社交网络实体、社交账号与公众用户标识的对应关系中获取用户的公众用户标识。

社交API系统为了安全性才使用信息请求中携带的密钥信息进行验证操作。当然社交API系统也可以不执行该验证操作，直接根据该信息请求携带的该票据信息和该公众社交网络实体获取用户的公众用户标识，这样授权网关发送的该信息请求也可以不携带该密钥信息。

在验证通过后，社交API系统还临时生成个令牌信息，将该公众用户标识和该令牌信息存储在公众用户标识与令牌信息的对应关系中。

步骤212：社交API系统向授权网关发送信息响应，该信息响应携带该用户的公众用户标识和该令牌信息。

步骤213：授权网关接收该信息响应，根据该信息响应向社交API系统发送用户信息请求，该用户信息请求携带该公众用户标识和该令牌信息。

如果授权方式为第二种授权方式，则授权网关在接收第一信息响应后直接跳转到步骤215，以根据第二域名向业务系统发送该公众用户标识。如果授权方式为第一种授权方式，则还需要向社交API系统发送用户信息请求，以请求用户的用户信息。

步骤214：授权API系统接收该用户信息请求，根据该用户信息请求获取用户的用户信息，向授权网关发送该用户的用户信息。

具体地，授权API系统接收该用户信息请求，根据该用户信息请求携带的该公众用户标识，从公众用户标识与令牌信息的对应关系中获取对应的令牌信息，如果获取的令牌信息与该用户信息请求携带的该令牌信息相同，则验证通过，并根据该用户信息请求携带的公众用户标识，从社交账号、公众社交网络实体与公众用户标识的对应关系中获取用户的社交账号，根据用户的社交账号获取用户的用户信息，向授权网关发送用户的用户信息。

社交API系统为了安全性才使用该用户信息请求中携带的令牌信息进行验证操作。当然社交API系统也可以不执行验证操作，直接根据该用户信息请求携带的该公众用户标识获取用户的用户信息，这样授权网关发送的用户信息请求也可以不携带该令牌信息。

步骤215：授权网关接收该用户的用户信息，向社交应用客户端发送第二消息，第二消息包括第二域名和用户的公众用户标识。

授权网关在接收到用户的用户信息后，还可以将用户的公众用户标识和用户信息存储在公众用户标识与用户信息的对应关系中。

步骤216：社交应用客户端接收第二消息，根据第二消息包括的第二域名向业务系统发送获取请求，该获取请求携带用户的公众用户标识。

步骤217：业务系统接收该获取请求，并向授权网关转发该获取请求。

如果授权方式是第一种授权方式，业务系统还需要向授权网关转发该获取请求，请求获取用户的用户信息，并继续执行后续步骤。

如果授权方式是第二种授权方式，业务系统接收到该获取请求后就得到用户的公众用户标识，不需要继续执行后续步骤218和219的步骤，然后根据用户的公众用户标识向社交应用客户端提供该业务标识对应的业务。

步骤218：授权网关接收该获取请求，根据该获取请求携带的公众用户标识获取用户的用户信息，向业务系统发送该用户的用户信息。

步骤219：业务系统接收用户的用户信息。

业务系统接收用户的用户信息后，根据该公众用户标识和该用户的用户信息向社交应用客户端提供该业务标识对应的业务。

在本发明实施例中，授权网关在接收到业务系统发送的业务请求后，使用授权网关包括的公众社交网络实体和与该公众社交网络实体绑定的第一域名代替业务系统向社交授权系统发起授权；在社交授权系统对该公众社交网络实体和第一域名验证通过后向社交API系统获取用户的公众用户标识，再向业务系统发送该公众用户标识；这样无需业务系统的域名与该公众社交网络实体绑定，当商家有多个业务系统时该多个业务系统的域名可以不同，商家可以根据各业务系统的域名分别对各业务系统进行管理和维护，增加业务系统的容灾隔离性。另外，虽然商家的业务系统的域名不同，但是每个业务系统通过授权网关都可以得到用户的公众用户标识，使得商家的每个业务系统都可以使用公众社交网络实体推广业务，都可以接入社交平台。

实施例四

由于商家可能包括多个业务系统，所以用户在其中一业务系统上请求业务后，还有可能在其他业务系统请求业务；或者，退出该一业务后并再次向该一业务系统请求业务。当用户首次在该一业务系统上请求业务时，授权网关可以按上述实施例的流程获取公众用户标识和/或用户信息。当用户在其他业务系统上请求业务，或者，退出该一业务系统后再向该一业务系统请求业务时，授权网关可以通过如下流程直接向业务系统提供用户标识和/或用户信息，避免重复请求社交平台授权，而造成资源浪费。参见图3，该流程包括：

步骤301：授权网关向社交应用客户端发送cookie消息，该cookie消息包括经过加密的该公众用户标识和时间标签，该时间标签定义了该cookie消息的有效时间范围。

本步骤可以在授权网关通过上述实施例获取到用户的公众用户标识后执行的，该时间标签可以是接收该公众用户标识的接收时间或是执行本步骤的当前时间等。

本步骤可以为：授权网关在获取到该公众用户标识后获取时间标签，通过预设非对称加密算法包括的加密密钥对该公众用户标识和该时间标签进行加密得到第一密文；通过对称加密算法包括的对称密钥对该第一密文进行加密得到第二密文，将该第二密文构成cookie消息。

cookie消息的形式可以为一个文本文件，所以授权网关可以将第二密文存储在该文本文件中，以将该第二密文构成cookie消息。

步骤302：社交应用客户端接收该cookie消息，并缓存该cookie消息。

在步骤之后，当用户向商家的某个业务系统请求业务时，用户可以触发社交应用客户端执行如下流程：

步骤303：社交应用客户端向业务系统发送业务请求，该业务请求携带业务标识和该cookie消息。

该业务标识是用户在社交应用客户端上打开业务系统对应的公众社交网络实体的应用界面后，从该应用界面中选择的业务的业务标识。

步骤304：业务系统接收该业务请求，根据该业务请求携带的业务标识确定授权方式，向授权网关发送该业务请求，该业务请求携带授权方式、其自身的第二域名和该cookie消息。

步骤305：授权网关接收该业务请求，对该业务请求携带的cookie消息进行解密得到该公众用户标识和时间标签。

本步骤可以为，通过对称加密算法包括的对称密钥对该cookie消息进行解密得到第一密文，通过预设非对称加密算法包括的解密密钥对第一密文进行解密得到该公众用户标识和时间标签。

步骤306：授权网关验证当前时间是否在该时间标签定义的有效时间范围内，如果在，执行步骤307或308。

本步骤可以为：授权网关可以计算当前时间与该时间标签之间的时间差，如果该时间差没有超过预设时间阀值，则验证出当前时间在该时间标签定义的有效时间范围内，否则，验证出当前时间不在该时间标签定义的有效时间范围内。

如果当前时间不在该时间标签定义的有效时间范围内，则授权网关按上述实施例中的202至219的步骤重新请求社交平台授权。

步骤307：授权网关在该授权方式为第一种授权方式时，根据第二域名向业务系统发送该公众用户标识和该公众用户标识对应的用户的用户信息，结束操作。

由于授权网关在执行上述实施例是保存了公众用户标识与用户的用户信息的对应关系。因本步骤可以为：授权网关根据该公众用户标识，从公众用户标识与用户的用户信息的对应关系获取对应的用户的用户信息，然后根据第二域名向业务系统发送该公众用户标识和该公众用户标识对应的用户的用户信息。

步骤308：授权网关在该授权方式为第二种授权方式时，根据第二域名向业务系统发送该公众用户标识，结束操作。

在本发明实施例中，当用户首次在商家的某一业务系统请求业务时，授权网关获取用户的公众用户标识，并在用户的社交应用客户端上缓存包括该公众用户标识的cookie消息。这样当用户退出该一业务系统后并再次在该一业务系统上请求业务或在商家的其他业务系统上请求，授权网关可以根据该cookie消息将向该一业务系统或其他业务系统提供公众用户标识和/或用户的用户信息，可以避免重新请求社交平台授权，避免资源浪费。

实施例四

参见图4，本发明实施例提供了一种对业务系统授权的装置400，应用于包括至少一个业务系统、所述装置400和社交平台的架构，在社交平台中所述装置400的第一域名和公众社交网络实体绑定，所述装置400包括：

接收模块401，用于接收业务系统在用户请求业务时发送的链接请求，该链接请求携带所述业务系统的第二域名，不同业务系统对应不同的域名；

获取模块402，用于根据所述链接请求获取所述社交平台对所述装置400的第一域名和公众社交网络实体验证通过后发送的所述用户的公众用户标识，所述公众用户标识用于在所述公众社交网络实体中标识所述用户；

发送模块403，用于根据所述第二域名向所述业务系统发送所述公众用户标识。

可选的，获取模块402包括：

发送单元，用于根据所述链接请求发送第一消息，所述第一消息包括所述公众社交网络实体和所述第一域名，所述第一消息用于所述社交平台在对所述第一域名和所述公众社交网络实体验证通过后发送所述用户的公众用户标识；

接收单元，用于接收所述社交平台发送的所述用户的公众用户标识。

可选的，所述发送单元，用于根据所述链接请求向所述用户的社交应用客户端发送第一消息，所述第一消息用于所述社交应用客户端向所述社交平台发送授权请求，所述授权请求携带所述用户的社交账号、所述第一域名和所述公众社交网络实体；

其中所述授权请求用于所述社交平台在对所述第一域名和所述公众社交网络实体验证通过后，根据所述社交账号和所述公众社交网络实体获取所述用户的公众用户标识。

可选的，所述接收单元，用于接收所述用户的社交应用客户端发送的票据信息，所述票据信息是所述社交平台验证通过后生成并发送给所述社交应用客户端的，且在所述社交平台中所述票据信息和所述社交账号绑定；

所述发送单元，用于向所述社交平台发送信息请求，所述信息请求携带所述票据信息和所述公众社交网络实体，所述信息请求用于所述社交平台根据所述票据信息和所述公众社交网络实体获取所述用户的公众用户标识；

所述接收单元，还用于接收所述社交平台发送的所述公众用户标识。

可选的，所述发送模块403，还用于向所述社交应用客户端发送cookie消息，所述cookie消息包括经过加密的所述公众用户标识和时间标签，所述时间标签定义了所述cookie消息的有效时间范围。

可选的，所述链接请求还携带所述社交应用客户端在所述用户请求业务时发送的cookie消息，所述cookie消息包括经过加密的公众用户标识和时间标签，所述时间标签定义了所述cookie消息的有效时间范围；

所述获取模块402包括：

解密单元，用于对所述cookie消息进行解密得到所述公众用户标识和所述时间标签；

确定单元，用于如果当前时间在所述时间标签定义的有效时间范围内，则将所述解密得到的所述公众用户标识确定为获取的所述社交平台对所述授权网关的第一域名和公众社交网络实体验证通过后发送的公众用户标识。

可选的，所述发送模块403，用于向所述用户的社交应用客户端发送第二消息，所述第二消息包括所述公众用户标识和所述第一域名，所述第二消息用于所述社交应用客户端根据所述第一域名向所述业务系统发送所述公众用户标识。

可选的，所述链接请求还携带授权方式，所述获取模块，还用于当所述授权方式用于请求授权所述用户的用户信息时，获取所述用户的用户信息；

所述发送模块，还用于向所述业务系统发送所述用户的用户信息。

在本发明实施例中，通过在接收到业务系统发送的链接请求后，使用装置400的公众社交网络实体和第二域名代替业务系统向社交平台请求获取用户的公众用户标识；这样无需业务系统的域名与该公众社交网络实体绑定，当商家有多个业务系统时该多个业务系统的域名可以不同，商家可以根据各业务系统的域名分别对各业务系统进行管理和维护，增加业务系统的容灾隔离性。

实施例五

参见图5，本发明实施例提供了一种对业务系统授权的装置500，所述装置500包括：

接收模块501，用于接收用户的社交应用客户端发送的业务请求；

发送模块502，用于根据所述业务请求向授权网关发送链接请求，所述链接请求携带业务系统的第一域名，所述链接请求用于所述授权网关获取所述用户的公众用户标识，所述公众用户标识是社交平台对所述授权网关的第二域名和公众社交网络实体验证通过后发送的；

所述接收模块501，还用于接收所述授权网关根据所述第一域名发送的所述公众用户标识。

可选的，所述发送模块502，还用于向所述授权网关发送获取请求，所述获取请求携带所述公众用户标识；

所述接收模块501，还用于接收所述授权网关根据所述公众用户标识发送的所述用户的用户信息，所述授权网关发送的所述用户的用户信息是所述授权网关根据所述公众用户标识从所述社交平台获取的。

实施例六

参见图6，图6是本发明实施例提供的对业务系统授权的装置600的结构示意图。该装置600可以为上述授权网关或业务系统，所述装置600可因配置或性能不同而产生比较大的差异，可以包括一个或一个以上处理器601、收发器602和存储器632，一个或一个以上存储应用程序642或数据644的存储介质630(例如一个或一个以上海量存储设备)。其中，存储器632和存储介质630可以是短暂存储或持久存储。存储在存储介质630的程序可以包括一个或一个以上模块(图示没标出)，每个模块可以包括对所述装置600中的一系列指令操作。更进一步地，处理器622可以设置为与存储介质630通信，在所述装置600上执行存储介质630中的一系列指令操作。

所述装置600还可以包括一个或一个以上电源626，一个或一个以上有线或无线网络接口650，一个或一个以上输入输出接口658，一个或一个以上键盘656，和/或，一个或一个以上操作系统641，例如Windows ServerTM，Mac OS XTM，UnixTM，LinuxTM，FreeBSDTM等等。

具体在本实施例中，所述装置600还包括有存储器，以及一个或者一个以上的程序，其中一个或者一个以上程序存储于存储器中，且经配置以由一个或者一个以上处理器执行。上述一个或者一个以上程序包含用于执行上述任一实施例提供的对业务系统授权的方法。

本领域普通技术人员可以理解实现上述实施例的全部或部分步骤可以通过硬件来完成，也可以通过程序来指令相关的硬件完成，所述的程序可以存储于一种计算机可读存储介质中，上述提到的存储介质可以是只读存储器，磁盘或光盘等。

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