"用戶增加"--快速身份認證明現用戶增加的技術和產品方案

"用戶增加"--快速身份認證明現用戶增加的技術和產品方案

1   引言

做爲一個互聯網產品,用戶量的增加是一個很是重要的衡量指標。 這是一個集合了銷售,市場,運營,技術的綜合能力。 本文將以非技術部分爲引子,而後落地爲技術方案,來針對 用戶增加 的目標來進行產品設計。git

2   身份認證技術

互聯網產品實現用戶增加,最開始部分就是來自於市場和運營人員的工做。github

用戶增加的 非技術 工做有:算法

  1. 銷售地推帶來早期標杆用戶
  2. 運營人員活動推廣帶來網絡用戶
  3. 市場人員PR和其它市場活動的企業宣傳帶來用戶

這部分非技術的工做落實到技術部分,就須要以下幾大系統作好支撐:瀏覽器

  1. 用戶自助註冊系統
  2. 用戶互相邀請系統
  3. 渠道推廣邀請系統

不管是哪一種技術方式,最後都會迴歸到一個很樸實地技術問題上面:「用戶的身份認證」安全

目前對用戶的身份認證最基本的方法分爲以下三種:服務器

  1. 基於信息祕密

    根據你所知道的信息來證實你的身份(what you know,你知道什麼), 好比:本身的人生經歷相關問答,還有帳號名和密碼微信

  2. 基於信任物體

    根據你所擁有的東西來證實你的身份(what you have,你擁有什麼), 好比:手機和U盾網絡

  3. 基於生物特徵

    根據獨一無二的身體特徵來證實你的身份(what you are,你是誰), 好比:指紋,虹膜,面部特徵架構

以上三種方法中, 基於 信息祕密 和基於 生物特徵 分別因爲使用成本和認證成本的關係, 沒有成爲當今的主流,因此本文在內容安排上將重點講目前使用最普遍的 基於信任物體 的認證方式。app

3   基於信息祕密

基於信息祕密是傳統身份認證主要實現方法有兩種:

  1. 基於帳號和密碼
  2. 基於用戶常見問題的問答

其中第1條,是在傳統的用戶註冊時身份認證最經常使用的方式,具備低成本和低平臺依賴性的特色。

在一些安全要求更嚴格的場景,則會啓用 「常見問題的問答」,好比:

  1. 你高中班主任的名字是?
  2. 你畢業後的第一份工做是?
  3. 你爸爸的名字是?

最後的效果是:

  • 這些問題越隱私,安全級別越高
  • 這些問題的答案越出乎意料,安全級別越高

可是這樣的反作用也特別明顯: 可能最後用戶本身也不記得本身設置的是什麼回答了, 其實這些問題本質上仍是設置的密碼。

  • 問題 對應 用戶名
  • 答案 對應 密碼

此方法的特色:

  1. 具備較高隱祕性
  2. 單次認證使用門檻高

4   基於生物特徵

目前普通網絡用戶能接觸到的常見的基於生物特徵的認證有:

  • 智能手機對用戶的指紋認證
  • 互聯網銀行進行面部識別認證

在一些軍工或者金融系統裏面,更高級的生物特徵認證有:

  • 基於眼球虹膜的認證
  • 基於掌紋的特徵提取
  • 基於脈搏的特徵提取

這些都會涉及到更高級的傳感器或者更高級的軟件算法,基於成本的問題,通常級別的信息系統都沒有采用。

5   基於信任物體

目前的一些廣義的 auth2.0 的方案基本上均可以概括爲此類。

此方法的特色是:認證方式能夠徹底拋棄密碼了

關於 基於信任的物體 能夠借用去年熱播的電視劇 《琅琊榜》 裏面的一個橋段來解釋:

「朝堂上要爭論 ‘有罪的太子母親’ 是否有資格參加皇室大型祭祀活動的問題, 隱居山裏的 周玄清 先生是這個學術領域的泰斗, 可是通常人都沒法請他出山, 可是梅長蘇則經過他已故的師傅黎崇先生(和周先生是舊時摯友)的信物--玉蟬, 將周老先生請出山,在朝堂辯論中取得勝利」

轉化爲當下信息系統的身份認證的語言就是:

  1. 梅長蘇想要擁有使用周玄清先生技能的權限

    但願利用周玄清先生的能力去取得辯論的勝利。

  2. 周玄清先生根本就不認識梅長蘇

    梅長蘇面貌已經徹底變了,通常的舊人徹底認不出來。 固然像蒙大統領和霓凰郡主這樣可以深度學習, 從多個維度提取特徵,並最終認出易容後的男主,這個設定有點BUG。

  3. 周玄清信任舊時摯友黎崇

  4. 梅長蘇擁有黎崇的貼身信物--玉蟬

    擁有玉蟬,基本上就等於和黎崇先生有非同尋常的關係

  5. 雖然黎崇已仙逝,但周玄清見到信物後就馬上答應出山幫忙

    周玄清能夠在不須要黎崇親自出面的狀況下,見信物就「受權」給梅長蘇

  6. 周先生在朝堂上幫助取得辯論勝利

    梅長蘇在取得受權的狀況下,享受到了周先生的服務

在當今現實生活中 信任物體 有以下幾種表現形式:

  1. 用戶擁有查看本身手機短信權限
  2. 用戶擁有接聽本身手機電話的權限
  3. 用戶擁有查看本身電子郵箱的權限
  4. 用戶擁有查看本身的app(微信/微博/支付寶)的權限

其實的解釋就是:

本系統 信任 某個平臺或者設備, 用戶若是可以出具你在那個平臺上有帳號或者設備使用權限的證實, 那麼此用戶就能夠成爲本系統的用戶而直接進入本系統。

可以利用好目前已經有的一些可信平臺,或者可信設備,能夠自然導流並沉澱用戶到本身的系統中。

這些平臺或者設備要有以下前提條件:

  1. 有本身的帳號體系
  2. 具有信息接收能力

目前符號這樣條件的基礎帳號有:

  1. 手機通話
  2. 手機短信
  3. 電子郵箱
  4. app(如:微信)

這幾種認證方式都是基於 "我擁有" 的原則來進行身份惟一性鑑定的。

傳遞信息的主流手段有以下幾種:

  1. 數字驗證碼
  2. 帶token的url
  3. 二維碼

而後和接收帳號進行組合,獲得以下的驗證矩陣表:


備註: Y 表示存在此方法;N 表示不存在此方法。

接下來的內容將針對此部分的認證方式進行詳細分析和展開。

5.1   數字驗證碼

「數字驗證碼」 的基本原理是:

服務器生成一串數字串,而後將這個信息發送到能收到用戶接收信息的帳號上, 而後根據用戶獲取此數字串後的輸入作對比, 以確認用戶所擁有此帳號的信息獲取權限,從而完成受權。

一個由 「數字驗證碼」 做爲驗證方式的註冊系統, 其主要步驟以下:

  1. 服務端生成一個隨機數字串(通常是4到6位)

  2. 服務端將信息主動推送到用戶信息接收帳號(文字或者音頻)

  3. 用戶交互
    1. 用戶打開應用,經過視覺或者聽覺的獲取信息
    2. 用戶記住此信息串內容
    3. 用戶切回服務界面
    4. 用戶輸入驗證碼
  4. 用戶完成註冊,進入信息系統

固然不一樣的信息接收方式,也會有以下幾個維度的不一樣:

  1. 接收信息的 載體的覆蓋成本
  2. 用戶 認證帳號記憶成本
  3. 服務商的 認證信息生成成本
  4. 用戶對 認證信息的獲取成本
  5. 用戶對 認證信息的使用成本
  6. 用戶 關係鏈成本

對每一個指標進行量化評分(1~5分),咱們能夠獲得以下的對比表:


收信載體覆蓋成本 :

毫無疑問手機號碼是覆蓋率最高的收集載體了,基本上不須要系統服務商去擔憂用戶覆蓋率的問題; 電子郵箱因爲QQ郵箱的功勞,在覆蓋率上也沒有太遜色;微信做爲裝機率極高的超級app,覆蓋率上也沒有太遜色。

認證帳號記憶成本 :

手機號碼是最容易被用戶記憶住;郵箱地址次之; 微信因爲只對第三方開放一個隨機長字符串,因此在第三方能得到的認證帳號是徹底沒有可記憶性的。

認證信息生成成本 :

  • 驗證短信目前市場價: 50元/1000條
  • 驗證郵件目前市場價:3元/1000封
  • 驗證微信:能夠認爲是免費的,但有服務號認證費用,300元/年

認證信息獲取成本 :

  • 短信直接在手機上打開短信應用就能夠看到驗證碼,比較便捷
  • 考慮到郵件則因爲並不是一開始就處於登陸態,絕大多數人也不會使用客戶端登陸郵件,獲取信息成本要高
  • 微信通常都是登陸態,打開微信消息便可得到驗證碼,比較便捷

認證信息使用成本 :

這三者都差很少,都是記住驗證碼,而後輸入驗證碼。

關係鏈獲取成本 :

  • 短信方式。經過用戶上傳手機號碼,獲取關係鏈條,並且質量最高。
  • 郵件方式。經過獲取郵件聯繫人,獲取關係鏈條,但質量沒手機號碼高。
  • 微信方式。通常的第三方徹底沒法獲取關係鏈條。

若是不考慮關係鏈,又特別在乎成本問題,其實微信方式也是個不錯的選擇。

使用以下步驟能夠實現揚長避短:

  1. 關注本系統的微信服務號
  2. 從微信服務號菜單中打開「註冊用戶」菜單進入註冊頁面
  3. 註冊頁面顯示出當前微信在本公衆號下的帳號ID(一個很難記憶的長字符串)
  4. 要求用戶輸入一個容易記憶的用戶名A(替代難記憶的微信第三方ID)
  5. 在微信瀏覽器裏面完成受權和簡單帳號名的綁定
  6. 後續可使用微信服務號主動給用戶微信推送 數字驗證碼
  7. 用戶收到驗證碼後,經過 用戶名A 和 驗證碼 完成登陸

本質上是:須要預先爲信息接收裝置綁定一個容易記憶的帳號。

基於 數字驗證碼 認證方法整個過程當中,交互過程以下:

  1. 打開收件箱或者登陸郵箱或者接聽電話
  2. 經過視覺或者聽覺獲取信息並記憶信息
  3. 切換軟件使用場景
  4. 鍵盤輸入驗證碼

評價:

  • 交互步驟:4步
  • 耗時:15s
  • 推薦指數: 3顆星

5.2   帶token的url

主要原理:信息系統服務商將帶token的url發送到指定的信息接收裝置中, 而後用戶從信息接收裝置中直接點擊打開url請求數據,完成受權。

以移動app登陸場景爲例子,主要遵循以下步驟:

  1. 用戶在app輸入用戶名
    • 能夠是手機號碼
    • 能夠是郵箱地址
    • 能夠是微信用戶名的替代名
  2. 服務商向接收載體發送帶token的url

  3. app使用token參數進行輪詢

  4. 只要輪詢檢查到url已經被請求過,則app認爲用戶認證經過

這實際上是對比短信驗證碼是更優秀的一種認證方式,由於它省去了用戶記憶驗證碼,和輸入難碼的環節。 整個驗證過程,交互動做以下:

  1. 打開收件箱或者登陸郵箱或者微信查看信息
  2. 點擊連接

評價:

  • 交互步驟:2步
  • 耗時:6s
  • 推薦指數:4顆星

此方法的缺點是:拋棄了那些使用連瀏覽器都沒法打開的老古董手機的用戶。 顯然按照目前的形勢來看,能夠不用考慮這部分稀缺用戶的感覺了。

5.3   二維碼或app調用

這種方式應該是目前最早進的一種認證方式了,只是開發難度稍微高一些。 可是若是開發能力不是問題,仍是建議儘可能使用此方法。

微信提供了三個途徑來開放其用戶信息:

  1. 微信app手機掃第三方服務商的二維碼
  2. 第三方服務商的app調用微信app
  3. 微信瀏覽器打開第三方服務商的頁面

可是若是不限制第三方服務商的服務在微信瀏覽器裏面使用的話,則認證方法只剩兩種:

  1. 微信掃第三方二維碼
  2. 第三方app調用微信app

這兩種方式都很是值得技術人員去研究理解並學會鑑賞。

其主要門檻在於:

  1. 須要企業資質去申請開發者權限
  2. 每一年會交300元的資格審查費用
  3. 要求開發人員具有必定的架構理解能力和軟件開發實現能力

若是以上三條不存在問題,那麼建議首選此方法。

這兩類認證方法的步驟以下:

  1. 生成二維碼或者第三方app發起調用微信app的請求
  2. 微信掃碼或者微信被調起後贊成受權

評價:

  • 交互步驟: 2步
  • 耗時: 3s
  • 推薦指數: 5顆星

6   本文總結

本文從「用戶快速增加」的 產品及運營目標 出發, 引出了「如何在技術上實現對用戶進行快速身份認證以減小用戶使用本系統門檻」的問題。 而後針對目前主流的一些認證技術和具體實踐中常見的認證明現方式進行了分析, 並針對目前最多見的 基於信任物體 的幾種具體認證方法進行了量化分析和評級。

最終的結論是: 微信的掃碼和app調用是最值得推薦的認證方式

但願本文的 分析過程及分析結果 可以對你們在進行產品設計和技術選型時有所啓發。

7   本文展望

本文主要解決在「利用現有的基礎信息平臺設施」的條件下信息系統關於用戶的兩個問題:

  1. 吸引新用戶註冊
  2. 用戶登陸認證

可是若是有更多的需求,例如,「對用戶進行詳細的權限角色限定」則須要開發商自行處理了。

開發商本身開發一個屬於本身信息體系的身份認證app, 從手機號碼/電子郵箱/微信這些帳號體系中完成自身app的 新用戶註冊和登陸功能 , 而後在app裏面進行角色和權限劃分。這樣能夠此app爲基礎,開發出針對本系統的不少特點的功能出來。

這就有點相似於:微信的註冊體系和登陸體系是依賴於手機號碼和短信的, 可是進入到微信系統後,它作出了掃碼登陸和調用app登陸這樣優秀體驗的認證方式。

最終若是app的功能足夠有特點,也一樣是可以把由第三方引入的用戶給沉澱下來,最終徹底脫離第三方。

app能夠做的功能有不少,例如:

  • 業務方面
    1. 掃碼登陸
    2. 掃碼審覈
    3. 掃碼付款
    4. 掃碼扣款
    5. 掃碼確認
  • 安全方面
    1. 進行安全等級劃分
    2. 本系統用戶徵信調查

等等,更多的功能就靠本身的想像力了。


做者: Harmo哈莫
做者介紹: https://zhengwh.github.io
技術博客: http://www.cnblogs.com/beer
Email: dreamzsm@gmail.com
QQ: 1295351490
時間: 2016-07
版權聲明: 歡迎以學習交流爲目的讀者隨意轉載,可是請 【註明出處】
支持本文: 若是文章對您有啓發,能夠點擊博客右下角的按鈕進行 【推薦】
相關文章
相關標籤/搜索