OAuth2
运维与安全 2017.4.1
我们在使用跨业务，平台性质的服务的时候，经常遇到的问题是，我怎么给所使用的网站授权。如果直接登录用户名密码的话，我总不能让平台上每个应用都知道我的用户信息，这样安全性太低了。针对这种情况，Oauth应运而生
OAuth在"客户端"与"服务提供商"之间，设置了一个授权层（authorization layer）。"客户端"不能直接登录"服务提供商"，只能登录授权层，以此将用户与客户端区分开来。"客户端"登录授权层所用的令牌（token），与用户的密码不同。用户可以在登录的时候，指定授权层令牌的权限范围和有效期。
OAuth2.0较1.0相比，整个授权验证流程更简单更安全，也是未来最主要的用户身份验证和授权方式。
（A）用户打开客户端以后，客户端要求用户给予授权。
（B）用户同意给予客户端授权。
（C）客户端使用上一步获得的授权，向认证服务器申请令牌。
（D）认证服务器对客户端进行认证以后，确认无误，同意发放令牌。
（E）客户端使用令牌，向资源服务器申请获取资源。
（F）资源服务器确认令牌无误，同意向客户端开放资源。
客户端必须得到用户的授权（authorization grant），才能获得令牌（access token）。OAuth 2.0定义了四种授权方式。
-
授权码模式（authorization code）
-
简化模式（implicit）
-
密码模式（resource owner password credentials）
-
客户端模式（client credentials）
基于严格的授权流程，授权码是最广泛的应用的模式。
以新浪微博授权为例子：
其中前四个是主要业务流程接口，主要授权接口是前两个，基于授权码模式，先获取普通授权，在用授权口令获取token
流程大致如图（我自己的业务系统）：
oauth2 在微服务中，可以集成到网关中使用，对于业务api进行签权过滤。还可以单独集成到子服务中，由子服务拿着token，直接去认证服务获取用户信息，而作为控制中心的认证服务，可以根据每种服务的特点，给与不同的权限，避免了一锅出的情况。而且，认证服务还可以借此汇总用户的活动状况，对整体安全性有个把控。
