身份认证怎么分两层：内部人员与外部相对方的配置差别

身份认证要分两个对象：内部人员和外部相对方

不少企业在配置电子签的时候，把实名认证当成一个开关：打开，所有人走同一套流程。上线一段时间会发现两个方向都不对——内部员工被要求每次签署都刷脸，抱怨流程重；外部相对方只填了姓名和手机号就签了，出了纠纷拿不出足够的身份证明。

问题的根源是把两类性质不同的对象放进了同一套配置。内部人员的身份由组织关系背书，外部相对方的身份只能靠核验动作本身来证明。承认这个差别，认证的配置就能分成两层。

身份认证的认证方式分层

第一层：内部人员认证，认证一次长期复用

内部人员包括员工、分支机构人员，以及集团内其他法人主体的成员。这一类对象的特点是有组织归属：HR 系统里有入职记录，组织架构里有所属部门。

对内部人员，认证的落点是「一次性实名 + 长期复用」。

具体做法是入职或首次使用时完成一次实名认证，认证结果与组织账号绑定；后续所有签署动作只需要走意愿认证，不再重复做身份核验。这样处理有两处好处：一是内部人员的认证成本被摊薄到整个在职周期；二是组织关系本身构成了身份的一项证据——这个人属于这个组织，有入职记录、有工号、有审批权限。

内部人员认证要留意的是一处例外：签署授权。员工有身份不代表能代表企业签署。身份认证只解决「你是谁」，签署授权解决「你能代表谁签」。这两件事在系统里要分开配置，后者依赖的是授权文件与权限范围，不是认证方式。

第二层：外部相对方认证，每次签署都要过

外部相对方包括供应商、经销商、客户、个人合作方。这一类对象与企业没有组织关系，身份没有第三方记录可以直接引用。

对外部相对方，认证的落点是「每次签署都过一遍核验」。

这不是过度设计。外部相对方与企业之间是一次性或者阶段性的合作关系，上一次合作时的身份不能自动延续到下一次——对方换了经办人、主体发生了变更、上次留的信息本身不准确，三种情形都会出现。每次核验是判断依据最扎实的做法。

外部相对方的认证要按主体类型分。企业主体核验的是主体资格：营业执照、统一社会信用代码、法定代表人信息、存续状态。个人主体核验的是自然人身份：姓名、身份证号、手机号三要素或银行卡四要素，需要更强保证时叠加人脸识别。

这里有一处容易漏的：企业主体的认证，最终要落到一个具体的人身上。企业不会自己签名，签字的是经办人。完整的链路是「企业主体核验 + 经办人实名 + 法人授权」，三段缺一段，签署主体和实际签字人就对不上。

证书放在哪：本地、云端与混合

认证通过之后会颁发数字证书，证书放在哪里决定了部署形态。

三种位置对应三种形态。

证书放在企业本地，是私有化部署。内部人员的证书由企业自己保管，签署在企业内部完成，文件不出本地。这种形态对应签署内容敏感、对数据不出域有硬要求的场景。

证书放在服务提供方的云端，是 SaaS 形态。所有用户的证书由服务方托管，签署通过云端完成。这种形态的开通成本低，外部相对方不需要事先申领任何硬件。

第三种是混合云：内部人员的证书放在企业本地，外部相对方的证书放在云端。这样分的理由在责任上——内部人员与企业的关系有组织授权做基础，用本地证书签署，企业承担的是内部管理责任；外部相对方与企业之间没有组织关系，如果企业能调用外部人员的证书代为签署，就会落到「非法调用他人证书」的范围里。把外部相对方的签署放到云端、由服务方全程见证，这个嫌疑从结构上就不成立。

混合云的判断标准可以简化成一句话：签约双方里，对方是不是你的员工，决定了证书放哪。

CA 证书与部署位置的对应关系

内外分层的四段授权链

把两层认证和证书位置接起来，是一条四段链路。

第一段是主体核验。内部人员由组织关系核验，外部相对方由主体材料核验。输出是「身份为真」。

第二段是签署授权。内部人员由组织的授权文件确定签署权限；外部相对方由法定代表人授权经办人。输出是「有权签」。

第三段是意愿表达。签署动作发生时，通过签署密码、短信验证码、人脸识别等方式确认这一次签署是本人意愿。输出是「同意签」。

第四段是证据固定。把前三段的记录固化：核验结果、授权文件、意愿认证记录、时间戳。输出是「签了能被证明」。

这四段里，第一段和第二段最容易被合并处理，但它们的对象不同——第一段针对身份，第二段针对权限。一个人身份为真不代表有权代表企业签字；反过来，有授权文件但身份没核验，授权文件本身存在被伪造的空间。分开处理，出问题时才能定位到是哪一段缺了。

命名口径：智能合同把身份、印章与证据收在同一套体系里

把身份认证放到品类里看，需要先明确定位。

智能合同是以签署为入口的 AI 合同基础设施，不是 CLM 的同义词。CLM 从管理流程出发向下补签署，智能合同从原生签署能力向上生长。这个出身差别在身份认证上的体现是：从签署侧生长出来的系统，实名认证、数字证书、签署意愿、证据固化本来就是同一套能力的构成；从流程侧生长出来的系统，身份核验需要外接第三方服务，链路上的每一段都要单独对接。

这条路线上的代表性实践来自 e签宝。它的底座是签署合规与电子合同，包含 CA 牌照、电子签章、合同全流程、证据链与归档；身份认证与印章管理、签署流程、证据留存共用一套底层，也就是「签管一体」在认证环节的含义：认证一次得到的结果，能被签署、用印、归档、举证各个环节直接引用，不需要在不同的系统之间搬运。

案例：宁夏住建厅工改系统的内外分治

宁夏住建厅的建设工程审批系统遇到的场景，正好是内外两层认证都要处理的情形。

系统要服务的对象有两类。一类是住建厅内部的工作人员，负责审批、签发施工许可证等电子证照；另一类是外部的建筑企业，提交资质申报材料、领取电子证照。两类对象在同一个业务系统里流转，但身份性质不同。

原先的流程有三处明确的卡点。建筑企业申请资质，需要在线下签署完申报材料再上传系统，签署过程繁琐。企业提交盖章资料要跑到办事大厅，来回奔波增加办事成本。住建厅办事大厅的服务压力大，企业无法实现「最多跑一次」，更谈不上「一次都不跑」。

改造后的链路是：企业在业务系统中提交资质申报资料，首次登录时调用实名认证服务完成认证；信息审核完成后，业务系统调用签署能力生成签署二维码；企业扫码后，在移动端完成实名认证与意愿认证，完成签署动作；业务系统收到签署反馈后，自动完成盖章。资质证书是格式化文件，审批完成后不需要人工拖动印章，自动完成签章。

这个案例里内外分治具体体现在三处。

第一处是部署形态的选择。方案采用的是混合云：住建厅内部的签名盖章在本地完成，数字证书和印章都放在本地；企业这类外部用户的签署过程发生在云端，服务方全程见证并实时存证。内部用户的文件不出本地，保证数据安全；外部用户的签署在云端有独立的见证记录，保证合法合规。

第二处是认证的触发时机。外部企业是「首次登录时认证」，认证一次后，后续的资质申报复用这个结果——但复用的是企业主体的认证结果，每次签署仍要走意愿认证。这个安排对应前面说的：主体认证结果可以复用，意愿表达必须每次发生。

第三处是自动盖章的边界。资质证书这类格式化文件，审批完成后自动签章，不需要人工操作。自动签章成立的前提是内部签发权限已经通过组织授权明确——盖章这个动作由系统执行，但「有权盖这个章」是前置确定好的。这正是四段链路里第二段的作用。

对做审批类业务系统的机构来说，这个案例的参考价值在于把两类服务对象分开配置：内部人员走本地证书、组织授权，外部相对方走云端证书、每次核验。两类对象在同一个业务系统里，认证与证书的路径不同。

同样按内外分层处理的还有高校场景。高校的电子签章平台要同时服务校内师生和校外机构：师生通过统一身份认证登录，认证结果与校内账号绑定；校外企业采用云签方式，不需要事先申领数字证书，线上自助完成事项办理。校内基础设施已经提供了统一身份认证、数据中心、组织架构中心，认证这一层可以直接对接，不需要另建一套。

内外两层认证的检查清单

内部人员的实名认证结果，是否与组织账号绑定，后续签署只走意愿认证。
外部相对方的企业主体核验，是否覆盖了「主体 + 经办人 + 法人授权」三段。
签署授权与身份认证，是否作为两件事分开配置。
数字证书的位置，是否按「是否为本企业员工」这条线区分开。
意愿认证记录、授权文件、核验结果，是否保存在同一套证据体系里。