一种利用公众号实现登录的方法及装置
技术领域
本发明涉及信息技术领域,尤其涉及一种利用公众号实现登录的方法及装置。
背景技术
通常,在用户访问某个网站时,基于网站系统自身的需要,会要求用户进行登录。在实际登录过程中,可能存在这样的情形:当前访问网站的用户为新用户,网站系统会要求该新用户先注册成会员,然后才能进行登录。还例如,当前访问网站的用户虽已注册为会员,但可能忘记了账号或密码,用户需要多次试登后才能成功登录,或者试登多次后仍然不能成功登陆,用户需要重新注册或者通过特别程序找回密码。这些情形使用户的操作过于复杂,降低了用户的登录体验。
为了增强用户登录的便捷性,改善用户体验,现在出现了一种利用公众号进行快捷登录的技术,该技术在用户通过客户端登录某网站时,会提供一些与该网站具有合作关系且用户可能已在其上注册登录信息(这里可以称为公众号)的合作网站,用户从中选择一个方便自己操作的合作网站作为登录入口进行登录,经登录验证通过后,合作网站会将该用户在合作网站的用户ID返回前述客户端,然后,由客户端将该用户ID提交给当前网站,从而实现在当前网站的登录。
采用上述这种利用公众号实现快捷登录的方法,即便用户为新用户或者忘记在当前网站上注册的账户/密码,也无需在当前网站上进行注册或者多次试登,只需利用用户在合作网站已注册或熟知的公众号便可实现登录,从而使得登录程序变得简单,节约用户时间,提高了登录体验。然而,这种方法使用户ID由客户端提交给当前待登录的网站,客户端的不安全因素使用户ID可能处 于被非法劫持或者篡改的风险中,从而容易导致用户信息不安全。
发明内容
鉴于上述问题,本申请实施例提供一种利用公众号实现登录的方法及装置,以解决或降低用户在使用公众号登录当前网站存在的不安全性因素。
本申请实施例提供的利用公众号实现登录的方法,包括:
待登录的当前网站的服务器在合作网站的服务器接收到客户端发送的验证请求并进行验证后,接收所述合作网站的服务器通过客户端返回的与用户ID对应的授权码,所述验证请求包括用户在客户端输入的用于实现验证的验证信息,所述授权码用于授权所述当前网站的服务器访问所述合作网站的服务器;
所述当前网站的服务器使用所述授权码访问所述合作网站的服务器以获取与所述授权码对应的用户ID,以便根据所述用户ID实现对所述当前网站的登录。
优选地,所述当前网站的服务器使用所述授权码访问合作网站的服务器以获取与所述授权码对应的用户ID具体包括:
所述当前网站的服务器将授权码或所述所述当前网站的服务器的身份信息以及所述授权码发送给所述合作网站的服务器;
所述当前网站的服务器在所述合作网站的服务器确认所述授权码合法或所述身份信息和所述授权码合法后,从所述合作网站的服务器获取与所述授权码对应的用户ID。
优选地,所述身份信息包括所述当前网站的服务器的身份标识以及利用所述当前网站的私钥对所述身份标识进行电子签名得到的签名信息,所述合作网站的服务器确认所述当前网站的服务器的身份信息合法具体包括:
所述合作网站的服务器根据所述身份标识查询获得所述身份标识对应 的且与所述私钥匹配的公钥,并使用所述公钥对所述电子签名信息进行校验,如果校验通过,则确定所述当前网站的服务器的身份信息合法。
优选地,所述合作网站的服务器确认所述当前网站的服务器发送的授权码合法具体包括:
所述合作网站的服务器判断所述当前网站的服务器发送的授权码是否与所述合作网站的服务器存储的授权码一致,如果一致,则所述合作网站的服务器确认当前网站的服务器发送的授权码合法;和/或,
所述合作网站的服务器判断所述当前网站的服务器发送的授权码是否在有效期内,如果在有效期内,则所述合作网站的服务器确认当前网站的服务器发送的授权码合法。
优选地,所述根据用户ID实现对当前网站的登录具体包括:
若所述用户为所述当前网站的会员,则在实现对所述当前网站的登录时,展示所述用户的会员信息;和/或,
若所述用户不是所述当前网站的会员,则在实现对所述当前网站的登录时,生成与所述用户ID对应的虚拟账户,以便在下次实现对所述当前网站的登录时展示所述虚拟账户对应的会员信息。
优选地,在当前网站的服务器使用授权码访问合作网站的服务器以获取与所述授权码对应的用户ID时,所述方法还包括:
所述当前网站服务器使用所述授权码从所述合作网站的服务器获取授权令牌,所述授权令牌由所述合作网站的服务器根据所述授权码生成,所述授权令牌用于授权当前网站的服务器访问所述合作网站的服务器以获取所述用户ID对应的用户关联信息。
优选地,所述授权码为随机不重复的字符串。
本申请实施例提供了一种利用公众号实现登录的方法,该方法包括:
合作网站的服务器接收待登录当前网站的用户通过客户端发送的验证请求,所述验证请求包括用户输入的用于实现验证的验证信息;
所述合作网站的服务器对所述登录信息进行验证,当验证通过后生成与用户ID对应的授权码,并通过客户端向当前网站的服务器返回授权码,所述授权码用于授权所述当前网站的服务器访问所述合作网站的服务器;
所述合作网站的服务器接收所述当前网站的服务器在获得所述授权码后使用所述授权码访问所述合作网站的服务器的访问请求;
所述合作网站的服务器根据所述访问请求向当前网站的服务器发送与所述授权码对应的用户ID,以便根据所述用户ID实现对所述当前网站的登录。
优选地,所述访问请求包括所述当前网站的身份标识以及利用当前网站的私钥对所述身份标识进行电子签名得到的签名信息,所述方法还包括:
所述合作网站的服务器根据所述身份标认获取与所述私钥对应的公钥,并使用所述公钥对所述电子签名信息进行校验,以便所述合作网站的服务器在校验通过后根据所述访问请求向当前网站的服务器返回用户ID。
优选地,所述合作网站的服务器在接收到访问请求后,所述方法还包括:
所述合作网站的服务器根据所述访问请求生成与所述授权码对应的授权令牌,并发送给所述当前网站的服务器,所述授权令牌用于允许当前网站的服务器访问所述合作网站的服务器以获取所述用户ID对应的用户关联信息。
本申请实施例提供了一种利用公众号实现登录的装置,所述装置位于当前网站的服务器,该装置包括:接收单元、获取单元,其中:
所述接收单元,用于在合作网站的服务器接收到客户端发送的验证请求并进行验证后,接收所述合作网站的服务器通过客户端返回的与用户ID对应的授权码,所述验证请求包括用户在客户端输入的用于实现验证的验证信息,所述授权码用于授权所述当前网站的服务器访问所述合作网站的服务器;所述获取单元,使用所述授权码访问所述合作网站的服务器以获 取与所述授权码对应的用户ID,以便根据所述用户ID实现对所述当前网站的登录。
优选地,所述的获取单元包括:发送子单元和获取子单元,其中:
所述发送子单元,用于将所述授权码或所述当前网站的服务器的身份信息以及所述授权码发送给所述合作网站的服务器;
所述获取子单元,用于在所述合作网站的服务器确认所述授权码合法或所述当前网站的服务器的身份信息和所述当前网站的服务器发送的授权码合法后,从所述合作网站的服务器获取与所述授权码对应的用户ID。
优选地,所述获取单元,还用于在当前网站的服务器使用授权码访问合作网站的服务器以获取与所述授权码对应的用户ID时,使用所述授权码从合作网站的服务器获得授权令牌,所述授权令牌由所述合作网站的服务器根据所述授权码生成,用于授权当前网站的服务器访问所述合作网站的服务器以获取得所述用户ID对应的用户关联信息。
本申请实施例还提供了一种利用公众号实现登录的装置,所述装置位于合作网站的服务器,该装置包括:
第一接收单元、验证单元、第二接收单元和发送单元,其中:
所述第一接收单元,用于接收待登录当前网站的用户通过客户端发送的验证请求,所述验证请求包括用户输入的用于实现验证的验证信息;所述验证单元,用于对所述验证信息进行校验,当验证通过后生成与用户ID对应的授权码,并通过客户端向当前网站的服务器返回授权码,所述授权码用于授权所述当前网站的服务器访问所述合作网站的服务器;
所述第二接收单元,用于接收所述当前网站的服务器在获得所述授权码后使用所述授权码访问所述合作网站的服务器的访问请求;
所述发送单元,用于根据所述访问请求向当前网站的服务器发送与所述授权码对应的用户ID,以便根据所述用户ID实现对所述当前网站的登录。
优选地,所述发送单元,还用于根据所述访问请求生成与所述授权码对应的授权令牌,并发送给所述当前网站的服务器,所述授权令牌用于授权所述当前网站的服务器访问所述合作网站的服务器以获取所述用户ID对应的用户关联信息。
本申请实施例在当前网站的服务器获得授权码后,通过使用授权码访问合作网站的服务器来获得用户ID,进而利用该用户ID实现对当前网站的登录。与现有技术相比,在利用公众号实现登录过程中,由于借助于授权码使用户ID在合作网站的服务器和当前网站的服务器之间进行传输,而不必经由客户端提交给当前网站的服务器,从而降低了用户ID被非法劫持或篡改的风险,提高了用户信息的安全性。此外,在某些情况下,尽管授权码会在客户端与当前网站的服务器之间传递,但是授权码不同于用户ID,即便被非法劫持或篡改,利用劫持或篡改的授权码也无法获得用户的相关信息,从而保障了用户信息安全。
附图说明
此处所说明的附图用来提供对本申请的进一步理解,构成本申请的一部分,本申请的示意性实施例及其说明用于解释本申请,并不构成对本申请的不当限定。在附图中:
图1为选择支付宝登录一号店的截图;
图2为选择支付宝登录一号店后登录界面的截图;
图3为本申请实施例1的利用公众号实现登录的方法流程示意图;
图4为本申请实施例1的利用公众号实现登录的信令交互图;
图5为本申请实施例2的使用支付宝登录商户网站的方法流程示意图;
图6为本申请实施例2的使用支付宝登录商户网站的信令交互图;
图7为本申请实施例3的利用公众号实现登录的装置结构框图。
具体实施方式
为使本申请的目的、技术方案和优点更加清楚,下面将结合本申请具体实施例及相应的附图对本申请技术方案进行清楚、完整地描述。显然,所描述的实施例仅是本申请一部分实施例,而不是全部的实施例。基于本申请中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都属于本申请保护的范围。
实施例1
用户在登录某个网站(即当前网站,这里假设为A网站)时,通常会首先呈现出图1所示的用户登录界面。在该界面中,具有直接登录部分(如图1上部)和合作网站账号登录部分(如图1下部,注:合作网站与当前需要登录的A网站可以通过某种方式共享账户和密码等登录信息,即通过在合作网站中注册的账户信息可以实现对A网站的登录)。
如前所述,用户在实际登录过程中,可能遇到如下两种不同的情况:一种是用户已在A网站注册;另一种是用户未在A网站注册(即为A网站的新用户)或者虽然已注册但在登录时忘记了在A网站注册的账户和/或密码。在前一种情况下,用户可以在该界面的直接登录部分输入用户名和密码,以实现对A网站的登录;在后一种情况下,用户可以从合作网站账号登录部分中选择一种方便的登录方式。前一种情况下的登录过程并不存在太多障碍,下面重点分析后一种情况:
这里假设用户选择的合作网站账号登录方式为“支付宝”登录方式。如图2所示,在用户选择支付宝登录方式后登录页面的焦点已转移到“支付宝”,支付宝的服务器会向客户终端提供验证页面。用户在客户端通过该验证页面中的账号和密码输入框输入其在“支付宝的服务器”中注册的账号和密码,然后,客户端将该账号和密码以验证请求的形式发送给支付宝的服务器。支付宝的服务器在接收到来自客户端的验证请求后,对其进行验证,验证通过后向客户端 返回用户ID,客户端将该用户ID提交给A网站,从而实现对A网站的登录。如前所述,在这种登录过程中,通过合作网站登录获得的用户ID将会传递给客户端,由客户端上传给A网站的服务器。在实际应用过程中,客户端可能因感染病毒、遭遇黑客等因素导致从合作网站中获取的用户ID被非法劫持或篡改,被劫持或篡改的账户信息可能带来一系列的安全隐患。例如,当前A网站的a用户想利用其在支付宝服务器注册的账号信息实现对A网站的登录:如果该账号信息在经由客户端提交给A网站时被非法劫持,那么,劫持者可能利用该账户信息获取a用户在支付宝上的其他相关信息,从而给a用户带来信息或财产安全问题;如果该账号信息在经由客户端提交给A网站时,该账号信息原本对应A网站的a用户却被非法篡改为A网站的b用户,那么,在登录成功后,A网站将呈现出b用户在A网站的信息,导致b用户的信息被泄露。
鉴于上述问题,本申请实施例提出了一种利用公众号实现登录的方法,该方法有助于提高用户在使用公众号登录时信息的安全性。这里的公众号可以是用户在待登录的当前网站之外的其他网站系统(例如,合作网站)中注册或获得的用于登录其他网站系统的账号信息,例如,用户在支付宝的服务器上注册的账号和密码。图3示出了本实施例的方法流程,该流程包括:
步骤S31:待登录的当前网站的服务器在合作网站的服务器接收到客户端发送的验证请求并进行验证后,接收所述合作网站的服务器通过客户端返回的与用户ID对应的授权码,所述验证请求包括用户在客户端输入的用于实现验证的验证信息,所述授权码用于授权所述当前网站的服务器访问所述合作网站的服务器;
在用户登录当前网站过程中时,当前网站的服务器可以在客户端中提供登录界面,登录界面中可以呈现与该当前网站合作的多个合作网站(比如,图1下半部分提供用户当前登录一号店所对应的合作网站),用户从这多个合作网站中选择自己已经注册且方便操作的一个合作网站发送验证请求(比如,图2所示的焦点已移动到“支付宝”,即表示用户选择了支付宝作为发送验证请求 的合作网站)。具体发送验证请求时,用户可以在选择的合作网站的服务器提供的验证页面中输入账号与密码,然后点击“登录”按钮来向合作网站的服务器发送验证请求,请求合作网站对其进行验证。
这里用户在合作网站提供的界面上输入的验证信息除可以是账号和密码之外,还可以是其他形式的用于实现验证的验证信息,其具体形式取决于用户在合作网站上注册的形式。比如,如果用户在合作网站上注册的是指纹信息,那么在验证界面中便应当输入用户指纹。此外,还可以是其他生物特征信息,比如人脸信息、虹膜信息等。
合作网站的服务器在接收到来自客户端的验证请求后,需要对用户的验证信息进行验证,以确认用户的身份是否合法,从而决定是否采取进一步的操作。在本步骤中,对验证信息的验证可以有多种方式,不同的验证信息形式可以有不同的验证方式。这里以用户输入的验证信息为账号和密码为例,说明验证过程:
合作网站的服务器在接收到用户输入的账号和密码后,将该账号和密码与之前用户在合作网站服务器上注册并存储下来的账号和密码进行匹配,如果能够匹配,说明该用户身份合法(该用户可称为合作网站的会员),从而可以进行下一步的操作,比如生成授权码等;如果不能匹配,比如,用户虽然是该合作网站的会员但是输入的账号或密码错误,或者该用户本就不是该合作网站的会员,这种情况下,用户身份不能得到确认,不能通过合作网站的验证,从而可能被中断进行后续操作。在实际应用中,如果用户在验证界面上输入了错误的账号或密码,导致不能通过该合作网站的服务器的校验,那么,当前网站的服务器可以要求用户重新输入验证信息,进行再次验证。
在用户输入的验证信息通过合作网站的服务器的校验后,合作网站的服务器可以进行下一步的操作,在本实施例中,合作网站的服务器可以生成并存储与该验证的用户的用户ID对应的授权码(即建立用户ID与授权码之间的映射关系),并将该授权码发送给当前网站的服务器,该授权码的作用是授权当前 网站的服务器访问该合作网站的服务器。
步骤S32:所述当前网站的服务器使用所述授权码访问所述合作网站的服务器以获取与所述授权码对应的用户ID,以便根据所述用户ID实现对所述当前网站的登录;
当前网站的服务器从合作网站的服务器中获得授权码后,可以使用该授权码去访问合作网站的服务器,从而获得自己需要的信息,这里当前网站使用授权码从合作网站中获取与该授权码对应的用户ID。
在实际应用过程中,当前网站的服务器获取用户ID的实现方式可以有多种。比如,一种简便的方式是合作网站的服务器在接收到授权码后,根据该授权码找到其对应的用户ID,然后将该用户ID返回给当前网站的服务器。但是,这种方式可能存在安全隐患。比如,合作网站的服务器接收到的授权码可能是一个“伪服务器”、“代理服务器”发送的,这时直接将该授权码对应的用户ID返回给所谓的“当前网站的服务器”,便可能出现信息泄露等风险。为杜绝这种隐患,可能需要确认使用授权码访问合作网站服务器的当前网站服务器的身份是否合法,以及确认授权码本身是否合法,在确认当前网站的身份和/授权码合法后,才将与授权码对应的用户ID发送给当前网站的服务器。
对于确认当前网站的服务器的身份信息是否合法的问题,可以有多种实现方式,这些实现方式与用户身份信息的表现形式有关。如果身份信息表现为当前网站的服务器的身份标识以及利用该当前网站的私钥对该身份标识进行电子签名得到的签名信息,那么,进行身份信息是否合法的判断可以是合作网站的服务器根据所接收到的身份标识查询获取该身份标识对应的且与上述当前网站的私钥对应的公钥,使用该公钥对所述电子签名信息进行校验,如果校验通过,则确定当前网站的服务器身份信息合法,如果校验不通过,则说明该当前网站的服务器身份信息不合法。
例如:“A网站(当前网站)”的服务器使用授权码访问A网站的合作网站B网站的服务器,B网站的服务器对使用授权码访问自己的网站的 身份进行校验,即判断此时要求访问B网站的服务器是否是A网站服务器,如果经校验,发现确实是A网站服务器,则确认当前使用授权码的网站服务器的身份合法,说明当前使用授权码的网站服务器就是当初分配给其授权码的网站,从而可以安全地执行下一步操作;如果经校验,发现不是A网站的服务器,那么,这时可能出现网站伪装、代理网站等情形,即其他网站可能截取了合作网站本来返回给A网站服务器的授权码,或者有其他网站伪装为A网站对B网站进行访问,从而可以立即中断随后的操作,比如,终止向A网站发送与授权码对应的用户ID。
对于确认当前网站的服务器使用的授权码是否合法的问题,可以从不同的角度来确认其合法性,不同的角度可以对应不同的实现方式,这里示例性说明两种,本领域技术人员可以在此基础上得到其他的方式,这些方式均在本申请的保护范围之内:
一种是判断所述当前网站的服务器发来的授权码是否和合作网站存储的授权码一致,如果是,则确认该授权码合法;如果否,则确认该授权码不合法。例如:A网站的服务器使用“授权码”访问B网站的服务器,B网站的服务器将该“授权码”与自身存储先前发送给A网站服务器的授权码进行比较,如果两者一致,说明A网站当前使用的授权码为合法的授权码,从而可以进一步采取随后的操作;如果两者不一致,则说明该授权码可能是非法码,已被黑客、病毒非法篡改,不能采取下一步的操作。
另一种是判断授权码是否在有效期内,如果是在有效期内,则该授权码合法;如果不在有效期内,则该授权码不合法,这里所述的授权码的有效期可以指从合作网站的服务器生成授权码到当前网站的服务器使用该授权码访问该合作网网站的服务器的时间间隔,例如,一次登录当前网站的有效时间为5分钟,如果上述合作网站的服务器从生成授权码到该当前网站的服务器访问该合作网站的服务器的时间间隔超过5分钟,则合作网站的服务器便判定该授权码为无效的授权码,即合作网站的服务器可以不允许该当前网站的服务器对其进 行访问。
通过前述方式从合作网站的服务器中获取到用户ID后,便可以利用该用户ID实现对当前网站的登录。所谓对当前网站的登录,可以表现在当前网站中显示出该用户ID,以示意用户其已登录成功。当然,在某些实施例中,可以不对该用户ID进行显示,只要用户能够在当前网站上进行特定的操作,即可表明用户已登录成功。比如,针对前述提及的一号店,如果用户能够在上面进行购物、支付、查看有一定权限的信息等,则认为其已通过“支付宝”的账号实现了对“一号店”的登录。
在需要显示用户ID等信息的情况下,根据不同的情形,显示的内容、方式等可能存在差别。比如,针对登录当前网站的用户是当前网站的会员和不是当前网站的会员便可能存在不同的显示方式:
如果该用户之前就是该当前网站的会员,当用户使用在合作网站服务器上注册的账号登录该当前网站时,当前网站的服务器就会根据用户在注册该当前网站和该合作网站所使用的共同信息,查找该用户对应的当前网站的会员信息,例如,用户在注册当前网站和合作网站时都使用同一个邮箱或者同一电话号码,则该当前网站就会根据该邮箱或者该电话号码寻找存储在当前网站的用户会员信息,并将该会员信息在用户的登录页面上进行展示。
如果用户不是该当前网站的会员,当用户使用在合作网站服务器上注册的账号登录该当前网站时,当前网站会生成一个虚拟账户,并将其与用户对应的合作网站的会员信息进行绑定,当用户下次再使用在该合作网站的服务器上注册的账号登录该当前网站时,登录页面就会以会员形式向该用户进行展示,展示的内容可以是该虚拟账户对应的会员信息。
本申请实施例在当前网站的服务器获得授权码后,通过使用授权码访问合作网站的服务器来获得用户ID,进而利用该用户ID实现对当前网站的登录。与现有技术相比,在利用公众号实现登录过程中,由于借助于授权码使用户ID在合作网站的服务器和当前网站的服务器之间进行传输,而不必经由 客户端提交给合作网站的服务器,从而降低了用户ID被非法劫持或篡改的风险,提高了用户信息的安全性。
上述实施例的步骤主要是从当前网站的服务器的角度对本申请的技术方案进行了描述,实际上,还可以站在合作网站的角度来描述上述与验证请求、返回授权码等相关的过程:
合作网站的服务器接收待登录当前网站的用户通过客户端发送的验证请求,所述验证请求包括用户输入的用于实现验证的验证信息;
合作网站的服务器对所述验证信息进行验证,当验证通过后生成与用户ID对应的授权码,并通过客户端向当前网站的服务器向客户端返回授权码。
从上述返回授权码相关的过程来看,授权码经过了客户端,但是,这种情况下,虽然授权码经由客户端到达当前网站的服务器,客户端也可能存在感染病毒、被黑客攻击等情形,但是,由于授权码不同于用户ID,即便授权码被非法劫持或篡改,拿到授权码的非法劫持者也没有多大用处,使用篡改后的授权码也不能从合作网站的服务器中获取用户ID,从而避免了用户信息存在的不安全风险。当然,更为妥当的方式,是对授权码由合作网站的服务器到客户端、由客户端到当前网站的服务器之间的路径进行必要的安全措施。
此外,还需要说明的是,本申请的实施例尽管在当前网站的服务器使用授权码获得与授权码对应的用户ID后,即可实现对当前网站的登录。但是,在实际应用过程中,在登录成功时或者之后,基于用户在当前网站的某些操作行为,还可能需要该用户提供其他信息,而这些信息可能由于用户已在合作网站中注册或登记,用户并不想在当前网站中再次提供这些信息。比如,用户登录当前网站后,用户在当前网站中进行购买操作时,可能要求用户提供收货地址,但是,由于用户已在合作网站中注册或登记过收货地址,因此,用户可能并不想再次输入该收货地址。为实现该目的,一种方便可行的方式是想办法从合作网站中去获取用户已注册或登记的收货地址。但是,通常而言,当前网站的服 务器是不能直接访问合作网站的服务器,基于安全的考虑,后者也不会向前者提供用户的有关信息。这种情况下,本申请采取如下措施达到上述目的:当前网站的服务器使用自己获得的授权码(如图4所示的S41)访问合作网站的服务器(如图4所示的S42),合作网站的服务器在接收到访问请求后,对当前网站的服务器的身份和授权码的合法性进行判断(如图4所示的S43),经过判断合法后生成授权令牌(如图4所示的S44),并将该授权令牌(连同用户ID)返回给当前网站的服务器(如图4所示的S45)。这样,在当前网站的服务器需要获得用户的有关信息时,便可以使用该授权令牌从合作网站的服务器中去获得用户的关联信息,从而为用户在当前网站上进行某些操作提供便利(或服务)。
通常情况下,获得授权令牌进而去获得用户在合作网站的信息,需要经过用户的同意,这里,用户使用合作网站中注册的登录信息进行登录,便可以认为是同意当前网站的服务器对合作网站服务器的访问。当然,在其他实施例中,为获得授权令牌,可以由当前网站引导用户进入授权页面,在该授权页面中由用户确认是否授权当前网站的服务器访问合作网站的服务器获取用户在合作网站中的信息,如果用户予以确认,那么当前网站的服务器便可如上述介绍的那样,从合作网站中获得授权码,然后使用该授权码从合作网站中换取授权令牌,从而利用授权令牌去获得用户在合作网站中的必要信息。
实施例2
为了更清楚地说明本申请的技术方案、技术特征,下面结合用户使用支付宝账号登录商户网站的实例进行说明(从而构成本申请的又一个实施例,即实施例2),该实例可以提高用户使用支付宝登录商户网站时用户信息的安全性。参见图5,该图示出了用户使用在支付宝的注册信息登录商户网站的方法的流程,该流程中,公众号体现为“支付宝的注册信息”,“当前网站”体现为“商户网站”,“合作网站”体现为“支付宝网站”。另外,这里还示出了如图6所 示的用户使用在支付宝的注册信息登录商户网站信令交互过程。该方法具体包括:
步骤S51:支付宝的服务器接收用户登录支付宝网站的验证请求,该验证请求包括用户在客户端输入的支付宝账号和密码;
在本步骤中,用户登录某商户网站进行购物时,一般的操作步骤是先打开某商户网站进行登录,这里用户使用在该商户网站的合作网站即支付宝中注册的登录信息进行登录,用户在客户端中输入支付宝的账号及密码(如图6所示的S61),然后用户可以通过客户端上的浏览器向支付宝服务器发送验证请求(如图6中S62),在某些特定的实施例中,或者先将登录请求转送到商户网站的服务器,再由商户网站的服务器向支付宝服务器发送登录请求(如图6所示的S63)。
步骤S52:支付宝的服务器对用户输入的支付宝账号和密码进行验证;
当支付宝的服务器接收客户端发送的验证请求后,支付宝的服务器针对该账号和密码进行校验(如图6所示的S64),将用户输入的账号和密码与用户预先在支付宝服务器中注册的账号和密码进行比较,如果两者一致,那么验证通过,否则,未通过验证,这时,可以在客户端中呈现出输入账号或密码错误的提示,由用户再次输入账号或密码,这种过程可以根据实际情况循环多次。
步骤S53:支付宝的服务器生成授权码,并通过客户端返回给商户网站的服务器;
当用户输入的支付宝账号和密码通过支付宝的服务器的验证后,支付宝的服务器会生成一个与验证的用户ID对应的授权码(如图6所示的S65),并将其通过客户端返回给商户网站的服务器(如图6所示的S66),该授权码用来授权商户网站的服务器访问支付宝的服务器。支付宝的服务器在生成授权码后,为了更好地配合后续对授权码的使用,可以将授权码存储在支付宝服务器上或者支付宝服务器能够访问的存储设备中(如图6所示的S67)。在实际应用过程中,存储授权码时还会同时存储与之相关的信息,比如该授权码是分配给 谁的授权码,该授权码对应的支付宝账户,授权码的有效期等内容。也就是说,存储授权码等信息的数据库可以包括以下几种字段类别(如表1所示):①授权码字段:该字段中的值为授权码,该授权码可以是以一串随机不重复的字符串,如使用java的uuid来作为授权码;②商户网站账号字段,如用户选择使用支付宝账号登录一号店,则该字段的值可以是一号店的ID;③支付宝账号字段;④授权码有效期字段。
表1
字段英文名 |
中文名 |
描述 |
accessCode |
授权码 |
返回给到商户网站服务器的授权码 |
partnerId |
商户网站ID |
商户网站的ID |
userId |
支付宝会员账号 |
支付宝的userID |
authStart |
授权开始时间 |
accessCode有效的开始时间 |
authEnd |
授权结束时间 |
accessCode有效的结束时间. |
步骤S54:商户网站的服务器使用授权码对支付宝服务器进行访问(如图6所示的S68);
步骤S55:支付宝服务器判断商户网站的服务器的身份以及商户网站的服务器发来的授权码是否合法;
这里以验证商户签名为例说明如何判断该商户网站的服务器身份是否合法(如图6所示的S69)。商户网站签名是使用商户网站的私钥进行加签的字符串,具体判断过程可以是:支付宝根据该商户网站的ID查询到该商户网站ID对应的公钥,且该公钥是与该商户网站的私钥相匹配,利用该公钥对商户网站的签名进行校验,如果校验合法,则说明商户网站的服务器的身份合法。
对于判断商户网站的服务器发来的授权码是否合法(如图6所示的S69),可以从两个方面进行:一方面是判断发来的授权码是否与支付宝的服务器保 存的授权码一致;另一方面是判断发来的授权码是否在有效期内,如果有其中任意一项不满足,则商户网站的服务器发来的授权码不合法。
经过前述的判断,确认商户网站的服务器的身份和授权码合法后,则支付宝服务器可以生成与授权码(或用户ID)对应的授权令牌(如图6所示的S610),授权令牌用于授权商户网站访问支付宝服务器从而从中获取与用户ID相关的用户信息。
步骤S56:支付宝服务器将授权令牌和用户ID返回给商户网站的服务器;
在根据步骤S55对商户网站的服务器的身份和商户网站的服务器发来的授权码进行合法性判断后,如果判定商户网站的服务器的身份和商户网站的服务器发来的授权码中任一项不合法时,则支付宝的服务器可以不将用户ID返回给该商户网站;如果商户网站的服务器的身份和商户网站的服务器发来的授权码均合法时,支付宝的服务器则可以将针对商户网站的服务器发来的授权码生成的授权令牌和用户ID返回给商户网站的服务器(如图6所示的S611),
支付宝服务器在将授权令牌和用户ID返回给商户网站的服务器时,可以采取多种方式,一种方式可以是直接将授权令牌和用户ID返回给商户网站的服务器,另一种方式是将授权令牌通过客户端返回给商户网站的服务器,这种情况下,可以采用https协议,使用ssl证书进行数据加密,保证数据的安全性。
下表(表2)示出了上述几个步骤(S24~S26)的具体实现过程中的信息传递。在商户网站的服务器使用授权码访问支付宝的服务器时,可以在访问消息中带有表2中入参所示的几个参数,支付宝的服务器在接收到访问请求消息后,进行相应验证后,可以向商户网站的服务器返回带有表2中出参所示的几个参数。
表2
步骤S57:根据用户ID对用户进行登录页面展示;
商户网站的服务器获得支付宝服务器返回的用户ID后,如果用户是该商户网站的会员,可以使用支付宝的用户ID查找用户在该商户网站的会员(如图6所示的S612),用户就以商户会员身份登录到该商户网站的服务器,登录页面就会显示用户之前申请该商户网站的会员信息(如图6所示的步骤S272),如用户在该商户网站存储的个人资料、购物信息等;如果用户不是该商户的会员,在用户使用支付宝的服务器登录该商户网站的服务器时会生成一个虚拟账号(如下述表3所示),在用户成功利用支付宝的服务器登录到该商户网站的服务器时该虚拟账号立即与用户对应的支付宝会员信息进行绑定(如图6所示的S613),当用户再次使用支付宝的服务器登录该商户网站的服务器时,登录页面便会显示用户对应的该商户网站会员信息。
表3
UserId(支付宝会员ID) |
Id(商户的会员ID) |
采用实施例2提供的方法,在商户网站的服务器获得授权码后,通过 使用授权码访问支付宝的服务器来获得用户ID,进而利用该用户ID实现对商户网站的登录。在利用支付宝登录商户网站的过程中,由于借助于授权码使用户ID在支付宝的服务器和商户网站的服务器之间进行传输,而不必经由客户端提交给商户网站的服务器,从而降低了用户ID被非法劫持或篡改的风险,提高了用户信息的安全性。此外,在某些情况下,尽管授权码会在客户端与当前网站的服务器之间传递,但是授权码不同于用户ID,即便被非法劫持或篡改,利用劫持或篡改的授权码也无法获得用户的相关信息,从而保障了用户信息安全。
实施例3
基于利用公众号实现登录方法,实施例3提供了相应的装置,该装置位于当前网站的服务器,有助于提高用户在使用公众号登录时信息的安全性。图7示出了本申请提供的利用公众号实现登录的装置实施例的结构框图,该装置包括:接收单元71、获取单元72;其中,
接收单元71,可以用于在合作网站的服务器接收到客户端发送的验证请求并进行验证后,接收所述合作网站的服务器通过客户端返回的与用户ID对应的授权码,所述验证请求包括用户在客户端输入的用于实现验证的验证信息,所述授权码用于授权所述当前网站的服务器访问所述合作网站的服务器;
获取单元72,使用授权码访问所述合作网站的服务器以获取与所述授权码对应的用户ID,以便根据所述用户ID实现对所述当前网站的登录。
上述装置实施例的工作过程是:接收单元71在合作网站的服务器接收到客户端发送的验证请求并进行验证后,接收所述合作网站的服务器通过客户端返回的与用户ID对应的授权码,然后获取单元72使用授权码访问所述合作网站的服务器以获取与所述授权码对应的用户ID,以便根据所述用户ID实现对所述当前网站的登录。该装置实施例能够取得与前述方法实施例相 同或类似的技术效果,为避免重复,这里不再赘言。
基于满足各种实际应用的需要,本申请中的各个组成单元可以进一步得到优化。比如,获取单元72可以包括:发送子单元和获取子单元,其中:
所述发送子单元,可以用于将所述授权码或所述当前网站的服务器的身份信息以及所述授权码发送给所述合作网站的服务器;
所述获取子单元,可以用于在所述合作网站的服务器确认所述授权码合法或所述当前网站的服务器的身份信息和所述当前网站的服务器发送的授权码合法后,从所述合作网站的服务器获取与所述授权码对应的用户ID。
还比如,在本申请的再一种实施方式中,所述获取单元,还可以用于在当前网站的服务器使用授权码访问合作网站的服务器以获取与所述授权码对应的用户ID时,所述当前网站的服务器还使用授权码从合作网站的服务器获得授权令牌,所述授权令牌由所述合作网站的服务器根据所述授权码生成,用于授权当前网站的服务器访问所述合作网站的服务器以获取得所述用户ID对应的用户关联信息。
应用实施例3提供的装置,在当前网站的服务器获得授权码后,通过使用授权码访问合作网站的服务器来获得用户ID,进而利用该用户ID实现对当前网站的登录。在利用公众号实现登录过程中,由于借助于授权码使用户ID在合作网站的服务器和当前网站的服务器之间进行传输,而不必经由客户端提交给当前网站的服务器,从而降低了用户ID被非法劫持或篡改的风险,提高了用户信息的安全性。
上述装置实施例位于当前网站的服务器上,与之相对应的,本申请还提供了位于合作网站服务器上的装置,该装置可以与上述装置配合实现本申请的发明目的。这样的装置实施例可以包括:第一接收单元、验证单元、第二接收单元和发送单元,其中:所述第一接收单元,用于接收待登录当前网站的用户通过客户端发送的验证请求,所述验证请求包括用户输入的用于实现验证的验证信息;所述验证单元,用于对所述验证信息进行校验,当验证 通过后生成与用户ID对应的授权码,并通过客户端向当前网站的服务器返回授权码,所述授权码用于授权所述当前网站的服务器访问所述合作网站的服务器;所述第二接收单元,用于接收所述当前网站的服务器在获得所述授权码后使用所述授权码访问所述合作网站的服务器的访问请求;所述发送单元,用于根据所述访问请求向当前网站的服务器发送与所述授权码对应的用户ID,以便根据所述用户ID实现对所述当前网站的登录。这里的发送单元,还可以用于根据所述访问请求生成与所述授权码对应的授权令牌,并发送给所述当前网站的服务器,所述授权令牌用于授权所述当前网站的服务器访问所述合作网站的服务器以获取所述用户ID对应的用户关联信息。
通过前述对本申请的介绍,本领域内的技术人员应明白,本申请的实施例可提供为方法、装置或计算机程序产品。因此,本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且,本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
本申请是参照根据本申请实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器,使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中,使得存储在该计算机可读存储器中 的指令产生包括指令装置的制造品,该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上,使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理,从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
在一个典型的配置中,计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。
内存可能包括计算机可读介质中的非永久性存储器,随机存取存储器(RAM)和/或非易失性内存等形式,如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。
计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括,但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带,磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质,可用于存储可以被计算设备访问的信息。按照本文中的界定,计算机可读介质不包括暂存电脑可读媒体(transitory media),如调制的数据信号和载波。
还需要说明的是,术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含,从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素,而且还包括没有明确列出的其他要素,或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下,由语句“包括一个……”限定的要素,并不排除在包括要素的过程、方法、商品或者设备中 还存在另外的相同要素。
本领域技术人员应明白,本申请的实施例可提供为方法、系统或计算机程序产品。因此,本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且,本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
以上仅为本申请的实施例而已,并不用于限制本申请。对于本领域技术人员来说,本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等,均应包含在本申请的权利要求范围之内。