"用户增长"--快速身份认证实现用户增长的技术和产品方案
"用户增长"--快速身份认证实现用户增长的技术和产品方案
1 引言
作为一个互联网产品,用户量的增长是一个非常重要的衡量指标。 这是一个集合了销售,市场,运营,技术的综合能力。 本文将以非技术部分为引子,然后落地为技术方案,来针对 用户增长 的目标来进行产品设计。
2 身份认证技术
互联网产品实现用户增长,最开始部分就是来自于市场和运营人员的工作。
用户增长的 非技术 工作有:
- 销售地推带来早期标杆用户
- 运营人员活动推广带来网络用户
- 市场人员PR和其它市场活动的企业宣传带来用户
这部分非技术的工作落实到技术部分,就需要如下几大系统做好支撑:
- 用户自助注册系统
- 用户互相邀请系统
- 渠道推广邀请系统
无论是哪种技术方式,最后都会回归到一个很朴实地技术问题上面:“用户的身份认证”。
目前对用户的身份认证最基本的方法分为如下三种:
- 基于信息秘密
-
根据你所知道的信息来证明你的身份(what you know,你知道什么), 比如:自己的人生经历相关问答,还有账号名和密码
- 基于信任物体
-
根据你所拥有的东西来证明你的身份(what you have,你拥有什么), 比如:手机和U盾
- 基于生物特征
-
根据独一无二的身体特征来证明你的身份(what you are,你是谁), 比如:指纹,虹膜,面部特征
以上三种方法中, 基于 信息秘密 和基于 生物特征 分别由于使用成本和认证成本的关系, 没有成为当今的主流,所以本文在内容安排上将重点讲目前使用最广泛的 基于信任物体 的认证方式。
3 基于信息秘密
基于信息秘密是传统身份认证主要实现方法有两种:
- 基于账号和密码
- 基于用户常见问题的问答
其中第1条,是在传统的用户注册时身份认证最常用的方式,具有低成本和低平台依赖性的特点。
在一些安全要求更严格的场景,则会启用 “常见问题的问答”,比如:
- 你高中班主任的名字是?
- 你毕业后的第一份工作是?
- 你爸爸的名字是?
最后的效果是:
- 这些问题越隐私,安全级别越高
- 这些问题的答案越出乎意料,安全级别越高
但是这样的副作用也特别明显: 可能最后用户自己也不记得自己设置的是什么回答了, 其实这些问题本质上还是设置的密码。
- 问题 对应 用户名
- 答案 对应 密码
此方法的特点:
- 具有较高隐秘性
- 单次认证使用门槛高
4 基于生物特征
目前普通网络用户能接触到的常见的基于生物特征的认证有:
- 智能手机对用户的指纹认证
- 互联网银行进行面部识别认证
在一些军工或者金融系统里面,更高级的生物特征认证有:
- 基于眼球虹膜的认证
- 基于掌纹的特征提取
- 基于脉搏的特征提取
这些都会涉及到更高级的传感器或者更高级的软件算法,基于成本的问题,一般级别的信息系统都没有采用。
5 基于信任物体
目前的一些广义的 auth2.0 的方案基本上都可以归纳为此类。
此方法的特点是:认证方式可以完全抛弃密码了。
关于 基于信任的物体 可以借用去年热播的电视剧 《琅琊榜》 里面的一个桥段来解释:
“朝堂上要争论 ‘有罪的太子母亲’ 是否有资格参加皇室大型祭祀活动的问题, 隐居山里的 周玄清 先生是这个学术领域的泰斗, 但是一般人都无法请他出山, 但是梅长苏则通过他已故的师傅黎崇先生(和周先生是旧时挚友)的信物--玉蝉, 将周老先生请出山,在朝堂辩论中取得胜利”
转化为当下信息系统的身份认证的语言就是:
- 梅长苏想要拥有使用周玄清先生技能的权限
-
希望利用周玄清先生的能力去取得辩论的胜利。
- 周玄清先生根本就不认识梅长苏
-
梅长苏面貌已经完全变了,一般的旧人完全认不出来。 当然像蒙大统领和霓凰郡主这样能够深度学习, 从多个维度提取特征,并最终认出易容后的男主,这个设定有点BUG。
周玄清信任旧时挚友黎崇
- 梅长苏拥有黎崇的贴身信物--玉蝉
-
拥有玉蝉,基本上就等于和黎崇先生有非同寻常的关系
- 虽然黎崇已仙逝,但周玄清见到信物后就立刻答应出山帮忙
-
周玄清可以在不需要黎崇亲自出面的情况下,见信物就“授权”给梅长苏
- 周先生在朝堂上帮助取得辩论胜利
-
梅长苏在取得授权的情况下,享受到了周先生的服务
在当今现实生活中 信任物体 有如下几种表现形式:
- 用户拥有查看自己手机短信权限
- 用户拥有接听自己手机电话的权限
- 用户拥有查看自己电子邮箱的权限
- 用户拥有查看自己的app(微信/微博/支付宝)的权限
其实的解释就是:
本系统 信任 某个平台或者设备, 用户如果能够出具你在那个平台上有账号或者设备使用权限的证明, 那么此用户就可以成为本系统的用户而直接进入本系统。
能够利用好目前已经有的一些可信平台,或者可信设备,可以天然导流并沉淀用户到自己的系统中。
这些平台或者设备要有如下前提条件:
- 有自己的账号体系
- 具备信息接收能力
目前符号这样条件的基础账号有:
- 手机通话
- 手机短信
- 电子邮箱
- app(如:微信)
这几种认证方式都是基于 "我拥有" 的原则来进行身份唯一性鉴定的。
传递信息的主流手段有如下几种:
- 数字验证码
- 带token的url
- 二维码
然后和接收账号进行组合,得到如下的验证矩阵表:
备注: Y 表示存在此方法;N 表示不存在此方法。
接下来的内容将针对此部分的认证方式进行详细分析和展开。
5.1 数字验证码
“数字验证码” 的基本原理是:
服务器生成一串数字串,然后将这个信息发送到能收到用户接收信息的账号上, 然后根据用户获取此数字串后的输入做对比, 以确认用户所拥有此账号的信息获取权限,从而完成授权。
一个由 “数字验证码” 作为验证方式的注册系统, 其主要步骤如下:
服务端生成一个随机数字串(一般是4到6位)
服务端将信息主动推送到用户信息接收账号(文字或者音频)
- 用户交互
-
- 用户打开应用,通过视觉或者听觉的获取信息
- 用户记住此信息串内容
- 用户切回服务界面
- 用户输入验证码
用户完成注册,进入信息系统
当然不同的信息接收方式,也会有如下几个维度的不同:
- 接收信息的 载体的覆盖成本
- 用户 认证账号记忆成本
- 服务商的 认证信息生成成本
- 用户对 认证信息的获取成本
- 用户对 认证信息的使用成本
- 用户 关系链成本
对每个指标进行量化评分(1~5分),我们可以得到如下的对比表:
收信载体覆盖成本 :
毫无疑问手机号码是覆盖率最高的收集载体了,基本上不需要系统服务商去担心用户覆盖率的问题; 电子邮箱由于QQ邮箱的功劳,在覆盖率上也没有太逊色;微信作为装机率极高的超级app,覆盖率上也没有太逊色。
认证账号记忆成本 :
手机号码是最容易被用户记忆住;邮箱地址次之; 微信由于只对第三方开放一个随机长字符串,所以在第三方能获得的认证账号是完全没有可记忆性的。
认证信息生成成本 :
- 验证短信目前市场价: 50元/1000条
- 验证邮件目前市场价:3元/1000封
- 验证微信:可以认为是免费的,但有服务号认证费用,300元/年
认证信息获取成本 :
- 短信直接在手机上打开短信应用就可以看到验证码,比较便捷
- 考虑到邮件则由于并非一开始就处于登录态,绝大多数人也不会使用客户端登录邮件,获取信息成本要高
- 微信一般都是登录态,打开微信消息即可获得验证码,比较便捷
认证信息使用成本 :
这三者都差不多,都是记住验证码,然后输入验证码。
关系链获取成本 :
- 短信方式。通过用户上传手机号码,获取关系链条,而且质量最高。
- 邮件方式。通过获取邮件联系人,获取关系链条,但质量没手机号码高。
- 微信方式。一般的第三方完全无法获取关系链条。
如果不考虑关系链,又特别在意成本问题,其实微信方式也是个不错的选择。
使用如下步骤可以实现扬长避短:
- 关注本系统的微信服务号
- 从微信服务号菜单中打开“注册用户”菜单进入注册页面
- 注册页面显示出当前微信在本公众号下的账号ID(一个很难记忆的长字符串)
- 要求用户输入一个容易记忆的用户名A(替代难记忆的微信第三方ID)
- 在微信浏览器里面完成授权和简单账号名的绑定
- 后续可以使用微信服务号主动给用户微信推送 数字验证码
- 用户收到验证码后,通过 用户名A 和 验证码 完成登录
本质上是:需要预先为信息接收装置绑定一个容易记忆的账号。
基于 数字验证码 认证方法整个过程中,交互过程如下:
- 打开收件箱或者登录邮箱或者接听电话
- 通过视觉或者听觉获取信息并记忆信息
- 切换软件使用场景
- 键盘输入验证码
评价:
- 交互步骤:4步
- 耗时:15s
- 推荐指数: 3颗星
5.2 带token的url
主要原理:信息系统服务商将带token的url发送到指定的信息接收装置中, 然后用户从信息接收装置中直接点击打开url请求数据,完成授权。
以移动app登录场景为例子,主要遵循如下步骤:
- 用户在app输入用户名
-
- 可以是手机号码
- 可以是邮箱地址
- 可以是微信用户名的替代名
服务商向接收载体发送带token的url
app使用token参数进行轮询
只要轮询检查到url已经被请求过,则app认为用户认证通过
这其实是对比短信验证码是更优秀的一种认证方式,因为它省去了用户记忆验证码,和输入难码的环节。 整个验证过程,交互动作如下:
- 打开收件箱或者登录邮箱或者微信查看信息
- 点击链接
评价:
- 交互步骤:2步
- 耗时:6s
- 推荐指数:4颗星
此方法的缺点是:抛弃了那些使用连浏览器都无法打开的老古董手机的用户。 显然按照目前的形势来看,可以不用考虑这部分稀缺用户的感受了。
5.3 二维码或app调用
这种方式应该是目前最先进的一种认证方式了,只是开发难度稍微高一些。 但是如果开发能力不是问题,还是建议尽量使用此方法。
微信提供了三个途径来开放其用户信息:
- 微信app手机扫第三方服务商的二维码
- 第三方服务商的app调用微信app
- 微信浏览器打开第三方服务商的页面
但是如果不限制第三方服务商的服务在微信浏览器里面使用的话,则认证方法只剩两种:
- 微信扫第三方二维码
- 第三方app调用微信app
这两种方式都非常值得技术人员去研究理解并学会鉴赏。
其主要门槛在于:
- 需要企业资质去申请开发者权限
- 每年会交300元的资格审查费用
- 要求开发人员具备一定的架构理解能力和软件开发实现能力
如果以上三条不存在问题,那么建议首选此方法。
这两类认证方法的步骤如下:
- 生成二维码或者第三方app发起调用微信app的请求
- 微信扫码或者微信被调起后同意授权
评价:
- 交互步骤: 2步
- 耗时: 3s
- 推荐指数: 5颗星
6 本文总结
本文从“用户快速增长”的 产品及运营目标 出发, 引出了“如何在技术上实现对用户进行快速身份认证以减少用户使用本系统门槛”的问题。 然后针对目前主流的一些认证技术和具体实践中常见的认证实现方式进行了分析, 并针对目前最常见的 基于信任物体 的几种具体认证方法进行了量化分析和评级。
最终的结论是: 微信的扫码和app调用是最值得推荐的认证方式。
希望本文的 分析过程及分析结果 能够对大家在进行产品设计和技术选型时有所启发。
7 本文展望
本文主要解决在“利用现有的基础信息平台设施”的条件下信息系统关于用户的两个问题:
- 吸引新用户注册
- 用户登录认证
但是如果有更多的需求,例如,“对用户进行详细的权限角色限定”则需要开发商自行处理了。
开发商自己开发一个属于自己信息体系的身份认证app, 从手机号码/电子邮箱/微信这些账号体系中完成自身app的 新用户注册和登录功能 , 然后在app里面进行角色和权限划分。这样可以此app为基础,开发出针对本系统的很多特色的功能出来。
这就有点类似于:微信的注册体系和登录体系是依赖于手机号码和短信的, 但是进入到微信系统后,它做出了扫码登录和调用app登录这样优秀体验的认证方式。
最终如果app的功能足够有特色,也同样是能够把由第三方引入的用户给沉淀下来,最终完全脱离第三方。
app可以作的功能有很多,例如:
- 业务方面
-
- 扫码登录
- 扫码审核
- 扫码付款
- 扫码扣款
- 扫码确认
- 安全方面
-
- 进行安全等级划分
- 本系统用户征信调查
等等,更多的功能就靠自己的想像力了。
作者: | Harmo哈莫 |
---|---|
作者介绍: | https://zhengwh.github.io |
技术博客: | http://www.cnblogs.com/beer |
Email: | dreamzsm@gmail.com |
QQ: | 1295351490 |
时间: | 2016-07 |
版权声明: | 欢迎以学习交流为目的读者随意转载,但是请 【注明出处】 |
支持本文: | 如果文章对您有启发,可以点击博客右下角的按钮进行 【推荐】 |
"用户增长"--快速身份认证实现用户增长的技术和产品方案的更多相关文章
- 基于FormsAuthentication的用户、角色身份认证
一般情况下,在我们做访问权限管理的时候,会把用户的正确登录后的基本信息保存在Session中,以后用户每次请求页面或接口数据的时候,拿到 Session中存储的用户基本信息,查看比较他有没有登录和能否 ...
- 项目开发-->身份认证及用户登录模块
1.首先明确的两个问题 如何判断当前申请是由一个已登录用户发起的?如果Request.IsAuthenticated为true,则表示是一个已登录用户. 如何获取当前登录用户的登录名?如果是一个已登录 ...
- 基于FormsAuthentication的用户、角色身份认证(转)
一般情况下,在我们做访问权限管理的时候,会把用户的正确登录后的基本信息保存在Session中,以后用户每次请求页面或接口数据的时候,拿到 Session中存储的用户基本信息,查看比较他有没有登录和能否 ...
- 构建具有用户身份认证的 React + Flux 应用程序
原文:Build a React + Flux App with User Authentication 译者:nzbin 译者的话:这是一篇内容详实的 React + Flux 教程,文章主要介绍了 ...
- Angular SPA基于Ocelot API网关与IdentityServer4的身份认证与授权(一)
好吧,这个题目我也想了很久,不知道如何用最简单的几个字来概括这篇文章,原本打算取名<Angular单页面应用基于Ocelot API网关与IdentityServer4+ASP.NET Iden ...
- 理解ASP.NET Core - 基于Cookie的身份认证(Authentication)
注:本文隶属于<理解ASP.NET Core>系列文章,请查看置顶博客或点击此处查看全文目录 概述 通常,身份认证(Authentication)和授权(Authorization)都会放 ...
- Nancy 学习-身份认证(Forms authentication) 继续跨平台
开源 示例代码:https://github.com/linezero/NancyDemo 上篇讲解Nancy的Basic Authentication,现在来学习Nancy 的Forms身份认证. ...
- asp.net core 使用identityServer4的密码模式来进行身份认证(一)
IdentityServer4是ASP.NET Core的一个包含OpenID和OAuth 2.0协议的框架.具体Oauth 2.0和openId请百度. 前言本博文适用于前后端分离或者为移动产品来后 ...
- Angular SPA基于Ocelot API网关与IdentityServer4的身份认证与授权(三)
在前面两篇文章中,我介绍了基于IdentityServer4的一个Identity Service的实现,并且实现了一个Weather API和基于Ocelot的API网关,然后实现了通过Ocelot ...
随机推荐
- Partition:增加分区
在关系型 DB中,分区表经常使用DateKey(int 数据类型)作为Partition Column,每个月的数据填充到同一个Partition中,由于在Fore-End呈现的报表大多数是基于Mon ...
- 04.SQLServer性能优化之---读写分离&数据同步
汇总篇:http://www.cnblogs.com/dunitian/p/4822808.html#tsql 过段时间再继续写文章吧,本来准备把SQLServer一个系列写完的,最近状态很差很不好, ...
- 利用XAG在RAC环境下实现GoldenGate自动Failover
概述 在RAC环境下配置OGG,要想实现RAC节点故障时,OGG能自动的failover到正常节点,要保证两点: 1. OGG的checkpoint,trail,BR文件放置在共享的集群文件系统上,R ...
- Spring aop应用之实现数据库读写分离
Spring加Mybatis实现MySQL数据库主从读写分离 ,实现的原理是配置了多套数据源,相应的sqlsessionfactory,transactionmanager和事务代理各配置了一套,如果 ...
- Visual Studio 2013 添加一般应用程序(.ashx)文件到SharePoint项目
默认,在用vs2013开发SharePoint项目时,vs没有提供一般应用程序(.ashx)的项目模板,本文解决此问题. 以管理员身份启动vs2013,创建一个"SharePoint 201 ...
- 解决 Could not find com.android.tools.build:gradle 问题
今天拉同事最新的代码,编译时老是报如下错误: Error:Could not find com.android.tools.build:gradle:2.2.0.Searched in the fol ...
- Oracle Standard Error 列表
今天,我特意从网上找了一些,以及自己平时总结的,关于错误编号和说明,平时我们在写项目的时候,往往是可能会出现下面这些错误,例如:违反唯一约束,无效的会话ID,等等.希望对大家有点帮助!可以看看,如果有 ...
- Centos6.5 配置Nginx开机自启动
1.在/etc/init.d/目录下创建 nginx 文件,内容如下: #!/bin/sh # # nginx - this script starts and stops the nginx dae ...
- 豪情-CSS解构系列之-新浪页面解构-01
目录: 一. 新浪的布局特点 二. 内容细节的特点 三. 其中相关的一些基础技术点 1. 常见布局方法 2. 布局要点 3. Debugger误区 4.列表 5.字体颜色 6.CSS选择符 7.CSS ...
- RCP:ISourceLocator翻译
org.eclipse.debug.core.model.ISourceLocator A source locator locates source elements for stack frame ...