先提供一个例子用以理解OAuth的流程模式，小明住在一个小区中，小区中有各种属于小明的资源，比如一套房子（私有的），花园（共有的），快递柜（半私有半公有），小区的进入需要有门卡。一天小明去上班，有个快递员带着小明的快递来到小区门口，快递员没有进入的门卡，需要通过小明的远程同意，同意之后快递员能获取到一个令牌，然后方能进入小区，进入小区之后，快递员能使用到的内容包括了花园，快递柜，但是他没权限进入小明的房子里面。
在这个过程中，快递员的进入园区的权限是由小明给的，获取到令牌，即需要获取或者操作资源，是经过资源的拥有者的同意，系统才赋予了使用者获取资源的权限，但是并没有大到能使用其更私有的资源的权限。
OAuth授权机制就是这样的过程，在登陆有道云笔记的时候，我会选择新浪账号去登陆，这个时候有道云就会向新浪的服务器发起授权请求，以获取其token，在用户使用密码登陆了之后，并同意授权，则会将token返回有道云客户端，有道云取到这个token之后便可以使用其去访问我在新浪的用户名，当然这个token能拿到的资源会很有限，不可能和新浪的客户端能拿到的数据相比。
当然OAuth自然是不止这一种模式。实际上OAuth授权机制是有4种模式用于向第三方客户端进行授权的。授权码、隐藏式、密码式、客户端凭证。这四种不管是哪一种，都需要先向系统备案当前客户端。以在进行授权时能对其进行验证，没备案过的客户端将不能通过验证，如在开发中经常使用到的client_Id。
- 授权码方式：授权码是通过前端获取的，但是令牌的都会由后端保存，通讯也是由后端处理，前后端的分离可以避免令牌的泄漏。A网站中提供了一个链接，跳转到B网站，获取到授权码之后，传给A网站的后端，再由后端通过该授权码去获取令牌，具体是向某个回调url发送一个json串，其中包含有令牌等信息，则在此获取到了相应的令牌。安全性最高。
- 隐藏式：web应用为纯前端应用，没有后端的，则必须将token存储在前端中，这种则是直接颁发令牌，所有会省去了授权码的获取过程。第一步则是提供一个连接，要求用户跳转到授权界面，当通过了授权之后，将会将令牌通过回掉url传回传给前端，则前端能直接获取token并存储，之后的再使用即可。安全性不高，通常是会话期间有效，
- 密码式：则是将账户密码直接告诉第三方应用，场景则是必须对该第三方应用高度信任，风险大。
- 凭证式：适用于没有前端的命令行，只需要client_id和client_secret来确认第三方应用的身份，通过了即可颁发令牌，该令牌是用于该应用向资源服务器发送请求使用的。
OAuth有个很重要的特性就是为了支持http的情况下，也可以防止被攻击，这样想就能理解为什么会在授权码方式的情况下使用code和secret了，当然还有status字段，用上的话可以防止“攻击者让受害者登陆攻击者的帐号”从而完成攻击（详细看第二篇参考博文）。
参考博客：www.ruanyifeng.com/blog/2019/0… 关于OAuth安全需要关心的事情：www.chrisyue.com/security-is…
