概述
认证微服务（Auth Service）是物联网平台的安全基石，统一负责设备连接认证、用户登录鉴权、API访问控制、权限管理。物联网平台面临双重认证挑战：一是海量设备的身份验证——每台设备需在连接时证明"我是谁"，且需防止伪造、重放、中间人攻击；二是多角色用户的访问控制——运维人员、开发者、终端用户对平台资源的访问权限各不相同，需细粒度管控。认证微服务将这两类需求抽象为统一的身份与权限模型，为整个平台提供可信的身份底座。
与传统Web应用不同，物联网设备多为无人值守、资源受限，无法像人类用户那样通过浏览器完成OAuth授权流程。设备认证需支持预置密钥、证书、或基于硬件安全模块（HSM）的强认证，同时兼顾低成本设备的简化认证方案。认证微服务需在安全性与易用性之间取得平衡。
设备认证
一机一密（ProductKey + DeviceSecret）
每台设备在注册时分配唯一的ProductKey（产品标识）和DeviceSecret（设备密钥）。设备连接MQTT/CoAP时，使用ProductKey+DeviceName+签名（基于DeviceSecret）完成认证。优点：实现简单、适合批量生产；缺点：DeviceSecret若泄露需及时吊销。适用于智能家居、表计等中低安全场景。
X.509证书认证
设备预置客户端证书，连接时进行双向TLS认证。证书可设置有效期，支持自动轮换。适用于车联网、工业控制、金融支付等高安全场景。需配套PKI体系（证书颁发、吊销列表CRL、OCSP查询）。
预注册与动态发放
设备出厂前在平台预注册，获取临时凭证；首次上线时通过安全通道换取长期凭证。或采用批量导入+首次激活模式，降低产线烧录成本。支持物联网卡IMSI/ICCID与设备绑定，实现"卡机一体"认证。
用户认证
账号密码：传统方式，需配合密码强度策略、登录失败锁定、定期更换等。支持BCrypt、Argon2等安全哈希存储。
短信/邮箱验证码：无密码登录，适合移动端、临时访问。需防刷、防重放，验证码有效期通常5–10分钟。
OAuth2/OpenID Connect：支持微信、钉钉、企业微信等第三方登录，实现"扫码即登"。适用于SaaS化物联网平台，降低用户注册门槛。
JWT（JSON Web Token）：登录成功后颁发JWT，后续请求在Header中携带，服务端无状态校验。适合微服务架构，需注意Token刷新、黑名单（登出场景）的实现。
API鉴权与租户隔离
开放平台对外提供RESTful API时，每个请求需验证：①Token有效；②Token所属用户/租户有权限访问目标资源；③未超出API调用配额。多租户场景下，租户A不能访问租户B的设备与数据，需在数据层做租户ID过滤。认证微服务可提供统一的鉴权接口，供API网关调用，或通过JWT Claims嵌入租户ID、角色，由各业务服务自行校验。
权限模型（RBAC与扩展）
RBAC（基于角色的访问控制）：用户→角色→权限，如"运维员"角色拥有"查看设备""重启设备"权限，"开发者"拥有"调用API""查看日志"权限。支持角色继承、多角色叠加。
资源级权限：细粒度到"某用户对某产品的某批设备有读写权限"。适用于大型企业，不同部门管理不同设备组。
数据权限：控制用户可见的数据范围，如只能看本区域设备、本租户报表。与多租户、数据脱敏结合，满足合规要求。
物联网场景考量
设备认证需考虑弱网、高延迟环境下的超时与重试；支持设备固件升级后凭证的平滑迁移；与设备生命周期（预注册→激活→运行→停用→注销）联动。达希物联在物联网卡与设备管理场景中，认证服务需与运营商卡管理、设备档案打通，实现"卡+设备+用户"的统一身份体系。