补充一下认证方式，一般是由三大类方式及其组合实现：
What you are:
比如人的生理特征（指纹、面部识别、虹膜、声纹、DNA等）
What you know:
古代机关开启方式、密码、动态指令、预设安全问题、最近和谁聊天、最近几次变动的密码、最近几次登录地址等
What you have:
身份证，医保卡，银行U盾牌，手机短信/电话语音发送验证码
但有一些就不太会好判断归属：
1、公安局开的身份证明或CA颁发给机构的证书，应该是“你有啥”，但很多时候直接被用于“你是谁”
2、图形动态验证码，用于判断“你是人不是机器”，这个算是“你是谁”的简单版本？
令牌内容
令牌不需要带太多的信息，但要满足一些基本要求：
1、令牌颁发机构标识
2、令牌被授予机构、APP、服务或网站标识
3、令牌类型（资源访问令牌、刷新令牌等）
4、令牌可访问的资源类型（头像、昵称、二维码等）
5、令牌有效时间范围
6、令牌颁布机构签名和时间戳
7、数据组织方式其实用Json 或 编码过的字符串都可以
这样，三方就都可以快速验证令牌有效性。
数据权限
数据权限确实很多时候只能系统自己处理，很难跨行业通用，甚至同一行业不同机构也不尽相同。比如两个看似比较通用的场景：
1、当机构架构分为多级时，上级机构能看到下级哪些数据，平级之间能看到那些数据，下级机构能看到什么数据，各行业各类组织互不相同。如果只用功能权限的思路去解决这个问题，容易将功能权限弄得十分复杂。
2、此外就是用户情况比较复杂，比如除了组织架构、岗位、职级外，还有职业证书相关权限控制、客户业务办理关系、项目组组成、项目组轮班，加上审核、稽核、多级质控等功能，仅是功能权限也是力有不逮。
而且，近些年来，各公司对数据权限和数据安全的要求都越来越高、越来越严格了。
凭证
感觉中文的“凭证”指的内容，比Credentials范围广很多。比如：
有时候，网页提示“请输入登录凭证”，说的就是用户名密码
有时候，请下载云主机“临时凭证”，说的就是登录证书
有时候，请出示入场凭证，说的就是一张狗牌
尤其是证书是否算凭证，感觉有些想不清楚。比如：下面的算凭证吗？
1、域控认证，Windows凭证管理器
2、Linux服务器可以通过ssh证书直接访问
3、一些云厂商可以申请临时ssh证书，允许远程访问
4、IOS程序发布时，需要开发者申请APP证书，并签名才能上传发表
5、接入云SDK时，需要申请AppId 和 SecretKey
6、TCP通讯时，采用TLS双证书双向加密
客户端敏感数据加密
对于客户端敏感数据加密的问题：
1、客户端对敏感信息加密，在通用浏览器、开放网络环境下，其实意义不大。如果一位黑客有能力干掉HTTPS通讯加密或者伪装为服务网站的话，替换掉网站前端代码也不是一件难的事情，这样无论如何加密信息都没有任何用途。同时，在客户端、服务的，这些敏感信息其实都有原文的，如果贡献了这两个地方，黑客可以同时获取明文和密文，所以加密也没啥用。
2、对于安全要求特别高，采用特殊通信协议，特殊信道，特殊设备、特殊浏览器的情况下，对于特别敏感的信息，进行二次加密是有必要的。因为设备和软件都难以得到，即使信道被监听，通信加密被破解，也要尽量拖延敏感信息被破解。
字证书有什么具体应用
1、机构、网站、身份认证
2、APP开发者认证
3、可执行程序开发者认证
4、控件开发者认证
5、API认证
6、文档的电子签章证书
7、大家自己搭建开发环境时有时需要自签名证书
其实还有很多咯。
除了顶级CA之外，其实CA也分等级的，这就涉及到了证书链。
此外，CA还要维护黑名单，吊销一些还在有效期之内的证书。
数据验证
之前只是零零散散有了一些想法，也落地了。但看完今天老师的讲解，感觉落地的很难看。
数据校验这部分，回顾了一下，我们真的做了很多，但十分十分的零散。根据各种要求，包括架构、运维、数据安全、数据合规要求、数据脱敏、敏感数据加密，每年都要折腾个几轮。此类代码横跨了文章中提到的全部层，实现方式从单纯的编码规范，到各层编码，到切面，到流水线扫描，到Jar包，到中间件、到持久化层验证，都有零散涉及。如果能尽量统一到 Bean Validation处理，就不至于每次加个要求，都要一通大改了。