信任的传递——为什么我们需要第三方授权？
在证书验证、基于JWT(Json Web Token)的身份认证、IDP(身份提供商)、SP(服务提供商)等技术中，都有一个可信的第三方，可明明是用户对资源或者服务的访问，为啥还要个第三方？
01 证书 —— 整个互联网中的信任传递
目的：解决两个节点之间的安全通信，常用的是用户访问某个具体的网站。
背景：基于现有的网络协议（如http），在其基础上对信道进行加密，保证安全。这就需要两个节点之间至少持有一个对方的公钥( 用这个秘钥加密的数据只有对方的私钥能解开)，然后才能建立加密的信道。
面临问题：作为用户，我不知道我以后会访问哪些网站，直接去网站获取它的秘钥需要通过网络传输，肯定不安全。操作系统也没办法提前就把信任的网站信息在出厂时就保存，因为有的网站可能还没开发出来。个人与商业网站都没办法相互取得信任。
具体说明：
信任的凭证：
终端与证书颁发机构之间：根证书
根证书终端与商业网站之间：根证书 + 证书
相关场景：自签名证书——不通过第三方颁发机构，自己生成证书与根证书。一般用于系统的非生产环境。
优点：自己生成，方便快捷，且不需要付费。
缺点：根证书不是通用的颁发机构的，需要手动将其安装到所有发起访问的终端中，有额外的维护成本。
02 IDP/SP 身份提供商与服务提供商 —— 企业级信任传递
目的：用户通过合法的身份访问资源和服务。
背景：统一管理身份，资源提供商不需要各自实现一套身份管理。
面临问题：企业或者平台中包含有很多不同的资源和服务，每个资源和服务都实现一套身份管理，这样操作不仅难以管理，用户体验很差，同时外部服务也无法公用已有的身份系统。
具体说明：
信任的凭证：
IDP到终端：用户在IDP中的验证信息，如用户名和密码
IDP到SP：OAuth 2.0中第三方IDP颁发给服务提供商的client id与secret、token等可以证明身份的信息；Saml中IDP生成的xml文件。
信任的传递：
认证中心到终端：用户使用的用户名和密码等认证信息，并生成返回xml文件（也可以直接跳转到SP）。
终端到资源服务器：发送这个xml文件，证明自己的身份。
相关场景：认证与具体服务耦合场景——在业务的服务中，同时包含了用户信息与相应权限的管理。
优点：适合简单场景，单体服务。
缺点：当服务变多时，容易演变为每个服务各自为战，自己都有一套身份系统，后期难以维护，用户体验也比较差。
03. 基于JWT的认证 —— 单次会话中的信任传递
目的：用户通过合法的身份访问资源和服务
背景：用户访问资源，不想每次请求都登录
面临问题：每次请求都填写用户名和密码的用户体验不可想象http协议每次请求都是相互独立的，需要进行验证
具体说明：
信任的凭证： 自验证的token
信任的传递：
浏览器cookie浏览器到资源服务器：发送请求的同时发送cookie中的token，token会在资源服务器或者网关进行验证，验证通过则为合法用户。
相关场景：基于session的认证——浏览器的cookie中只保存session id，没有完整的信息，服务端需要缓存session的具体信息。
优点：session id比较短，适用于用户信息太过庞大使得token过长的场景。
缺点：服务端需要额外维护所有登录的session信息，同时验证的时候需要再与认证中心进行交付。
总结：为什么需要第三方授权？
终端与资源服务器相互未知——终端不知道会访问那些网站，网站不知道会被哪些终端访问，于是需要一个长久运行的可信第三方建立信任。
资源服务器没有自己的身份管理系统——资源服务器关注与提供更好的资源访问，将身份认证服务交给更专业的服务。
资源服务器想提供更好的体验，更便捷的登录服务，比如使用Google，WeChate账户登录——资源服务器为提供更便捷的登录，让用户以其它已有的身份登录。
Reference：密码学基础
密码学的经典应用是对数据机密性的保护，不过在这篇文章中，我们涉及的是它的另外一个特性——不可伪造性。能够实现不可伪造性的技术不止一种：
非对称（公私钥）加密——在这种技术中，使用公钥加密数据，私钥解密数据是它的加密应用；同时可以使用私钥签名数据，公钥进行验证，因为私钥只有自己持有，公钥可以公开，就可以达到身份认证的目的。就好比一个人在支票上的签名，自己的笔迹是私钥，别人无法模仿；在不同银行开户时存底的签名模板是公钥，可以在不同银行存底；验签的过程就是银行将支票上的签名与存底模板进行比对的过程。
对称加密或者带盐Hash——在能够分享同一个秘钥，并且接受秘钥分享带来的风险的内部网络中，使用加密或者带盐Hash同样也可以实现身份验证的目的，将一份随机文本加密或者Hash后生成一个摘要，这段文本和摘要一起就组成了一个签名。