帮客户做WiFi网络实名认证系统选型的时候，身份核验方式这个问题经常卡住决策。短信验证码、身份证扫描、人脸识别、微信扫码……供应商能演示一堆方式，但适不适合自己的场景，说不清楚。这件事值得单独聊。

短信验证码是用得最广的方式，但不等于最合适

短信验证码（手机号+短信OTP）几乎是所有WiFi网络实名认证系统的标配。用户连上WiFi，弹出门户页，输手机号，收短信，填验证码，认证通过。流程简单，用户熟悉，部署成本低。

但它有几个绕不开的问题。手机号不等于真实身份，一个号可以有多个SIM卡，虚拟号码也能收短信，如果合规要求是"能追溯到具体自然人"，短信验证码本身是不够的。另外短信费用是持续的运营成本，场所日均认证量大的话，一个月累下来不是小数目。高并发时短信通道可能延迟，用户等不住就放弃，认证成功率比预期低。

短信验证码适合的场景：合规要求不严格（或对实名层级要求不高）、来访人员流动性强、无法预先建立人员名单的开放型场所。咖啡馆、商场公共WiFi、展会临时网络，短信验证码是合理选择。

身份证扫描的合规强度高，但实施门槛也高

需要严格实名的场所（如住宿设施）通常要求用户扫描身份证完成认证，身份证信息上传到公安认证系统核验，比对通过才放行。这是合规强度最高的方式，认证结果能追溯到具体自然人。

实施有两个门槛。接入公安部的实名认证接口需要资质，不是随便一家供应商都能对接；费用按认证次数计，量大的商用场所费用不低。用户体验那边，连个WiFi要拍身份证，很多人直接关掉，尤其是临时访客和老年用户，认证成功率会比预期差很多。

我见过一个住宿场所的项目，本来计划全面推行身份证认证，试运营一周后发现认证成功率很低，大量用户看到"扫身份证"就关掉了。最终改成入住时前台完成认证，用户不需要自己操作，解决了体验问题，但增加了前台的工作量。

微信/支付宝扫码认证的实际情况

微信授权登录作为WiFi网络实名认证系统的身份核验方式，原理是通过微信的unionID获取用户的微信身份，关联上网记录。这个方式的优点是用户体验好、操作简便，不需要输手机号，微信普及率高。

问题在于监管认可度。目前微信授权登录方式在大部分地区的监管文件里，没有被明确列为有效的实名认证方式。微信账号本身可以实名（绑了身份证），也可以不实名（只绑手机号），认证系统获取的是微信身份，不是直接的身份证信息，合规链条有缺口。

所以微信扫码认证在合规要求低的商业场所用得多（体验好、无费用），但在住宿、校园、政府场所等合规要求明确的场景里，通常只能作为补充方式，不能替代主认证。

企业/组织内网的认证逻辑和公共场所不同

写字楼、园区、企业内部的WiFi网络实名认证系统，身份核验逻辑和公共场所完全不同。员工身份已经在企业系统里有记录，认证系统通常直接对接LDAP/AD，员工用工号和企业域密码登录，不需要另外做手机号或身份证核验。

访客管理是独立的模块。来访者由前台登记、打印访客凭证，凭证上有临时上网账号（有效期和权限有限制），访客用这个账号认证上网，而不是用自己的手机号走公共流程。这个分层设计在安全性和体验上都比让访客自行认证更合理。

问题出在中小型企业：没有LDAP，员工账号管理在Excel里，访客管理没有系统。这类客户选WiFi网络实名认证系统，经常被供应商演示了一套企业级方案，但实施后发现账号维护全靠手动，反而增加了负担。选型时要先想清楚自己的账号体系是什么，再看系统能不能对接，而不是反过来。

多种方式组合的实际效果

实际项目里，很少是单一认证方式覆盖所有用户。酒店可能是：住客用前台实名认证（身份证），临时来访用手机号短信认证，员工走AD账号。校园可能是：在籍学生用校园卡账号，外部访客用短信验证码。

这种多方式并存的配置，需要WiFi网络实名认证系统的认证策略模块支持按用户类型、接入区域分配不同认证方式。不是所有系统都能灵活配置到这个程度——有些系统的认证方式是全局的，要改就全改。选型阶段要把自己的多用户场景列清楚，验证系统是否支持分组配置，别等上线后才发现不能按场景区分处理。