BLOG
Enjoy when you can, and endure when you must.
APR 21, 2016/后端开发与架构
移动应用的第三方平台登录在服务端的授权验证

如今,很多移动应用在做用户注册/登录的时候,为减少用户的交互成本,会考虑引入常用的第三方平台的开放登录授权来快速的将用户倒流到自己的平台中。在原来的第三方登录中,很多是采用基于 Web 的 Oauth 登录授权机制,在这种情况下,用户需要在 APP 弹出的网页中输入第三方平台的账号和密码进行登录,然后授权当前应用允许访问自己的账号。而现在更多的则采用的是所谓 SSO 授权机制,用户在点击第三方登录按钮后,应用会将用户引导至对应的第三方应用中,接下来只需点击授权按钮即可完成授权过程,大大增强了操作的便捷性和账号的安全性。但对于服务端开发者来说此时可能会发现,之前基于 Web 的 Oauth 登录授权会产生一个回调,服务器可以基于此来做授权验证。但在 SSO 这种机制下,回调会直接返回给应用本身而不经过服务器。这种时候应如何处理授权验证的问题呢?

解决方案就是针对不同的第三方平台,服务端再利用平台所提供的开放接口来对授权进行一次验证。

以QQ登录为例,其实在其官方文档中也提到了关于登录校验的解决方案:

1.2 需要考虑对OpenID和OpenKey做校验

应用接收页面请求时,必须对OpenID和OpenKey做校验,以预防XSS漏洞。
 OpenID的校验规则:长度为32的16进制字符串,字符在[0-9A-F]范围内。 开发者必须按照该规则对请求中传来的OpenID进行校验。(根据该规则生成的正则表达式:^([0-9A-F]{32})$) 
 OpenKey的校验规则:长度为不固定的字符串,不能为空。建议开发者不要检查openkey的长度,也不要在后台存储openkey,否则可能会导致用户无法登录。开发者可调用v3/user/is_login接口对请求中传来的Openkey做登录态校验。 

1.3 进行登录态校验的方法: 
 用户进入应用时,URL中会带有该用户的OpenID和openkey,这时应用只要调用腾讯的任意后台API,都可以验证用户的登录态是否合法。
 但是如果仅仅为了出于验证登录态 目的而去随意调用某一个OpenAPI,则会给后台服务造成很大的压力 。
因此更推荐应用在用户进入应用时通过以下方式进行登录态校验:
 (1) 方式1:调用v3/user/get_info 接口来验证登录态。该接口即可验证登录态又可以获取登录用户的信息,1个应用一般都需要获取登录用户的信息,因此调用本接口可一举两得。
 (2)方式2:调用专门的登录态校验接口v3/user/is_login。

在应用取得授权之后,应用可获得 OpenID 和 OpenKey。服务器可提供一个授权登录接口,要求应用将获得的 OpenID 和 OpenKey 传入,然后服务器可根据建议的方法调取 v3/user/get_info 接口(这样同时可以得到用户的基本信息作为注册资料写入),如果调取成功,则说明有效。这时服务器才考虑写入新的用户数据并完成注册/登录步骤。不过要注意获取用户信息的接口是需要取得权限的,因此要记得在授权登录的时候申请该权限,以 iOS 为例,要加入 kOPEN_PERMISSION_GET_INFO 权限参数

再以新浪微博为例。新浪微博关于这一点没有明确说明(或者我没有找到)。在应用取得授权之后,应用可获得 uid 和 access_token 等。因为新浪微博接口基本基于 OAuth2 官方标准规范来做的,因此可以在 OAuth2 的接口中找到 授权查询(oauth2/get_token_info) 的接口, 它可以查询用户 access_token 的授权相关信息,包括授权时间,过期时间和 scope 权限。该接口同时会返回该 access_token 对应的 uid,可以与应用获得的 uid 进行比对,以此来对授权进行验证。

由此可以看出,SSO 机制对于用户来说确实更为友好,但因为实现机制和平台提供的 API 接口与标准的 Oauth 授权过程有所不同,因此这对于开发者来说就带来了一些额外的工作。当然方法其实都大同小异,因此只要想到这一点,再找到合适的切入点,就可以很顺利的达到目的。

COMMENTS
12/05From ggg

ddddd

LEAVE COMMNT