从产品和架构的角度聊聊 “国家网络身份认证公共服务”

2,027 阅读10分钟

前言

2024年8月3日,中华人民共和国公安部 上线了 “国家网络身份认证公共服务”,开始了“国家级 IDaaS 服务” 的新网络身份认证方式。本文将从架构设计和产品设计的角度来分析此项服务将带来的一些“网络身份认证”的思考。

11722797892_.pic_副本.jpg

一、网络身份认证的发展历史

1. 无身份时期

互联网出现的早期,所有的网络请求都是匿名的,没有身份信息,且网络通信不够普及,普通人也无法随意的接入互联网。

这个时期的身份往往是通过 IP 地址作为认证,比如 1.2.3.4 表示 A单位5.6.7.8 表示 B单位

2. 匿名邮件身份时期

随着网络技术的发展,普通用户也可以接入互联网了,且随着网络基建设施(如 DNS, 邮件服务 等)的完善,网络身份认证进入了一个新的阶段。

用户可以使用 电子邮箱 作为自己的身份凭证,但此时的身份还是基于 离线点对点 认证,例如 张三对李四说自己的邮箱是 3@hamm.cn ,李四对张三说自己的邮箱是 4@hamm.cn ,那么此时张三和李四可以进行可信的通信,但从互联网侧来说,依然是匿名身份。

此时的互联网服务还不能称之为公共的基础设施,而是专业性比较强的沟通方式。

3. 普通身份认证时期(Web时代)

随着互联网进入 Web时代,越来越多的网站服务提供了 注册登录 等服务,用户可以在指定的网络服务内自定义自己的 账号密码昵称 等身份信息,这些身份信息可以作为 身份凭证,用于访问网络服务。

此时网络服务可能因自己的业务需求,需要用户上传 身份证真实姓名手机号 等信息作为 实名身份凭证,网络服务再依赖于国家身份证信息库对用户提交的 实名身份信息 进行验证。而此时的身份认证只能说解决了一些数据归属的权限控制问题。

与其说是 身份认证,不如说只是一堆 账号/密码

互联网正式进入了百家齐放的时代,随之而来的就是,用户可能需要记忆大量的账号密码。

此时,我们往往称之为 Web1.0 时代,PGC(Professionally-generated Content) 热火朝天的时代。 这个时代真正出现了 上网 的概念。

4. 统一身份认证时期(SSO/OAuth2.0)

随着大量的互联网应用的出现,类似一些企业级服务往往需要对自家的服务进行统一身份认证,此时需要一种 统一身份认证 的解决方案。

基于很多方案(如 会话/Cookie 共享、JWT 令牌等、CAS认证)的 SSO 单点登录服务开始在国内普及,但这些方案往往只应用在自家服务中。

而国内开始进入 OAuth2.0 时代,应该是 微博 开始在国内爆火的时代。

随着 新浪微博腾讯微博 等服务的大火,国内开始进入了 Web2.0 的时代,也同时进入了 UGC(User-Generated Content) 的时代。随着大量 SNS 服务的出现,互联网出现了 用户身份 的概念,也同时慢慢开始了 上网在网 的转变。此时,OAuth2.0 才广泛的在国内铺开。

OAuth2.0 的相关概念和标准可以自行查阅,可以理解为一个公共服务来做 身份认证 数据的提供和背书。

类似 微博QQ 因为自己的用户数量的庞大,开始使用 OAuth2.0 作为 统一身份认证 的标准,实现用户只需要注册一个账号,即可使用这个账号无缝登录到其他的 第三方服务 中。

至今, OAuth2.0 服务被大量应用到身份认证服务中,不论是自家的系统还是第三方的服务,都可以使用这个方案来对用户身份进行有限的共享,达到敏感数据统一管理,仅开放公开的身份信息(如 OpenID、昵称等)给到第三方服务。

但此时仍然存在 账号/密码记忆敏感信息泄露(身份证/姓名) 等问题。

5. 强制实名认证时期

2016年11月7日 通过的 《中华人民共和国网络安全法》第二十四条 规定,“网络运营者为用户办理网络接入、域名注册服务,办理固定电话、移动电话等入网手续,或者为用户提供信息发布、即时通讯等服务,在与用户签订协议或者确认提供服务时,应当要求用户提供真实身份信息。用户不提供真实身份信息的,网络运营者不得为其提供相关服务。”

这是中国大陆首次以法律形式明确网络实名制。

无规矩不成方圆。国家网络实名制维护了一个更加健康的网络环境,但同时也给用户带来一些问题。

大量的实名认证要求,用户上传身份证证件的入口增多,用户体验糟糕且用户身份证泄露概率变大。

6. “国家网络身份认证公共服务”时期

“国家网络身份认证公共服务” 来了,可以说解决了上述这些根本的问题。

二、网络身份认证的需求和背景

我们先来聊聊上面提到的一些问题:

1. 大量账号密码的记忆问题

随着大量的互联网服务的出现,每个平台可能都会有一套 登录/注册 服务,用户需要记住大量的账号密码。 前文中提到的 OAuth2.0 虽然可以解决这个问题,但都是基于当前互联网大厂的 OAuth2.0 标准,且不说 企业级应用 需要一些信用背书,个人用户依然需要记忆一些 互联网大厂 提供的账号密码等。

如果某大厂突然停止了服务,那用户将无法访问大量的服务。那么,如果出现了个 国家级OAuth2.0 服务呢?

国家网络身份认证公共服务: “你干脆报我名字得了!”

2. 敏感信息泄露问题

目前来看,即使我们使用了类似 QQ登录 微信登录 等提供的 OAuth2.0 来管理自己在各种应用中的身份,我们依然需要向 QQ/微信 等服务上传我们的身份证信息,依然存在这些大厂可能出现的身份证信息泄露的问题。

如果,出现了个 国家级OAuth2.0 服务,我们也不需要向这个服务上传身份证(国字头的服务,本身就知道我们的身份证),然后由这个服务来对其他的服务提供认证信息,那是不是就彻底解决掉这个敏感信息泄露的问题呢?

国家网络身份认证公共服务: “你干脆继续报我名字得了!”

3. 实名制上网的问题

都是国字头的服务了,实名制上网的问题已经彻底解决了。

三、国家网络身份认证架构构思

接下来我们将从架构的角度来构思这个服务,当然实际的服务架构可能跟我们的猜想和设计不一致。

1. 认证流程

每个人的身份证可以作为用户的唯一标识,用户可以基于身份证创建一个账号,然后设置一个口令作为密码。通过 OAuth2.0 标准将用户信息公开,比如提供 网号当前是否成年(非出生日期)性别籍贯(非详细地址) 等。流程图如下:

1.1 注册账号(办理身份证)

sequenceDiagram
    居民->>派出所: 办理出生证明
    派出所-->>公安部: 登记出生证明
    公安部-->>公安部: 生成身份证号
    公安部-->>公安部: 制作身份证
    公安部--)派出所: 邮寄身份证
    派出所-)居民: 办理完成

此时,用户拿到了身份证。

1.2 开通 OAuth2.0 服务

按目前看到的 国家网络身份认证公共服务 的设计,我们可以得到下面的图:

以下 国家网络身份认证中心App 将简称为 APP公安部身份数据库 将简称为 公安数据

sequenceDiagram
    居民->>APP: 打开App
    APP-->>APP: NFC 扫描身份证得到身份证 **加密ID**
    APP-->>APP: 设置口令、绑定手机号
    APP-->>公安数据: 上传 加密ID/手机号/口令
    公安数据-->>公安数据: 解密身份证
    公安数据-->>公安数据: 为用户初始化公开身份,如 **网号**
    公安数据--)APP: 返回网络公开身份
    APP-)居民: 开通成功

这里我们能看到, App使用了 NFC 扫描获取身份证里的 加密信息,保证了用户身份不被伪造。(如果没有NFC,可以去政务大厅等官方机构去开通),即使身份证被别人使用开通了,App上也能看到并远程注销身份。

2. 认证使用

接下来,我们将可以使用 OAuth2.0 的标准,来使用 国家网络身份认证公共服务 授权登录其他的网络服务,如 微信

目前很多应用都还没有接入,下面的图只是产品架构的设计思路。

sequenceDiagram
    居民->>微信App: 使用国家网络身份认证登录微信
    微信App-->>微信服务器: 请求使用国家网络身份认证公共服务登录
    微信服务器-->>微信服务器: 创建申请登录请求
    微信服务器--)微信App: 返回申请登录参数
    微信App->>国家网络身份App: 带参数跳转到国家网络身份认证公共服务App
    国家网络身份App-->>公安数据: 申请当前居民临时授权码
    公安数据-->>公安数据: 生成临时授权码
    公安数据--)国家网络身份App: 返回临时授权码
    国家网络身份App-)微信App: 带临时授权码跳转
    微信App-->>微信服务器: 通过临时授权码登录微信
    微信服务器-->>公安数据: 通过临时授权码查询居民网号等信息
    公安数据--)微信服务器: 返回网号、是否成年、性别、籍贯等信息
    微信服务器--)微信App: 登录成功
    微信App-)居民: 登录微信成功

接下来,用户不需要输入账号密码,也不需要短信验证,也不需要上传身份证,即可完成微信的登录。

而且,由于数据来源于公安部提供的信息,微信将认为,该居民已经实名。微信也并没有拿到真正的用户姓名、身份证号等敏感信息,上述的一些问题已经迎刃而解。

四、可能遇到的一些问题

1. 国家网络身份认证公共服务未开放

因为当前还是试点,所以笔者到目前为止没有看到有关开放授权的公告、文档、技术方案等,不过后续应该会陆陆续续的开放这些服务给第三方的一些应用服务对接了。

2. 应用侧还不支持

这个问题得等上面的问题解决了,可能加上一些国家的推广和要求,应用侧也会陆陆续续的支持使用这种方式进行身份认证了。

3. 认证服务生态建设

如一些第三方应用在实际使用中需要对接另外的一些还没有对接国家身份认证的服务时依然需要上传身份证等敏感信息,所以这个过程应该会有很长的过渡时间。

4. 安全/性能/风险

尽管减少了用户向第三方服务提供敏感信息的机会,但集中化的身份认证服务本身也可能成为黑客攻击的目标。面对数亿用户的日常使用,系统的稳定性和可扩展性是一个重要考量因素。

5. 国际互操作性

随着全球化的发展,需要考虑与其他国家和地区身份认证体系的互操作性。

五、笔者叹

在很多年前,国内的一些 SNS 社区开始爆火的时候,我们偶然有一个系统需要接入 QQ 登录和 微博 登录,作为开发者,笔者当时就吐槽了,今天对接这个,明天对接那个,太麻烦了。 为什么国家没有出个 国家级的IDaaS,这样我们就只需要对接一家了,而且是 权威的国家级 的。

这么多年过去了,这事还真来了。

六、更新

  • 2024年08月05日 15:48:55更新

笔者目前查阅相关公告和新闻之后,体验了一下,部分App已经支持使用 国家网络身份 进行授权登录了。但授权登录之后仍然需要用户绑定手机号。可能是还没改造完成吧,这一步起始已经不再需要了。