微服务系列之授权认证(一) OAuth 2.0 和 OpenID Connect
1.传统架构的授权认证
传统应用架构，用户使用账号密码登录后，可以使用前端cookie存储登录状态，也可以使用后端session方式存储登录状态，小应用这么做其实很高效实用，当应用需要横向扩展时，就需要共享登录状态，这时候session的基于asp.net state这种当前服务器进程方式存储就失效了，需要换成sqlserver或者redis作为session共享存储，这些都不是问题，这些前提都是单体应用架构的方案，但是在微服务架构里，服务拆分零散且前后端分离，后端以API方式提供服务的前提下，这种认证授权方式用不了拉，这时候就需要一个安全的、跨分布式的、高性能的认证授权方案来解决。
这些年围绕着授权鉴权(authorization)和身份验证(authentication)诞生了很多规范和协议。这里只讨论最主流的最新的规范和协议：OAuth2.0、OpenID Connect、JWT。8
2.OAuth 2.0
OAuth 2.0是关于授权鉴权的，一句话解释“OAuth 2.0是一种框架，其中服务的用户可以允许第三方应用程序访问他/她在服务中托管的数据，而无需向应用程序透露他/她的凭据”。
说一下Oauth2.0相关的名词：
- Resource Owner：资源所有者，就是某个应用的用户；
- Client：客户端，一个想要用这个资源用户的名义去做一些事情的应用”;
- Authorization Server：授权服务，前提是用户信任这个服务并且该服务拥有用户信息，用于颁发令牌给应用；
- Resource Server: 一个应用（API或者服务）;
- Redirect URI: 一个网址URL，当Resource Owner在Authorization Server上授权了Client后，Authorization Server将会把Resource Owner重定向到的地方，也称“Callback URL”;
- Authorization Code: 用户授权给client后通过RedirectUrl回调回去携带的code,用于client通过客户端模式向授权服务换取token;
- Access Token: Client和Resource Server交互所使用的令牌，携带的访问权限范围，是你授权时通过勾选给client的，然后client拿着这个用户名义的token就可以访问你的资源了; 一般使用的是JWT格式；
- Response Type: Client希望从Authorization Server收到的信息的类型，最常见的Response Type是code，也就是Client希望收到一个Authorization Code，也有Implicit隐藏式，password密码模式，Client Credential客户端凭证模式。
下面说一下几种常用授权类型的实际交互是怎么样的
(1) 授权码模式Authorization Code
(2)Implicit隐藏式
这种模式，跳过获取code的步骤，在客户端重定向到授权服务时，讲responseType换成token。
(3)password密码模式
这种是啥呢，需要用户非常非常信任client的时候，才使用这种模式，需要用户在clinet上输入账号密码，client拿着用户的账号密码去授权服务获取access token。
(4)Client Credential客户端凭证模式
这是client与client之间的通信，与用户没啥关系，这种用于，流程是，A客户端使用clientId和secret通过授权服务，获取访问B客户端的token。我们实战中，是业务系统，在中台认证中心里获取一个长期的可以访问中台某些服务的token，业务服务直接通信中台服务，于用户无关。
3.OpenID Connect
OpenID Connect实际上就是对于client来说，在OAuth 2协议上完善了身份认证的东西，并不是说Oauth 2.0没有提供认证能力，只是对于client来说，没有知道用户的认证过程，没有拿到用户认证信息而已，OIDC就是让OAuth把认证结果也告诉client,让client也知道了用户是认证过的。这样在授权码过程中如下图:
HTTP/1.1 302 Found Location: https://server.example.com/authorize? response_type=code &scope=openid%20profile%20email &client_id=s6BhdRkqt3 &state=af0dasd &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
在scope中增加了openid
HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store
Pragma: no-cache
{
"access_token": "dasdqwdqd",
"token_type": "Bearer",
"refresh_token": "casdqwfw",
"expires_in": 3600,
"id_token": "dsadwqdqdqwdqV4YW1wbGUuY29tIiwKICJzdWIiOiAiMjQ4Mjg5
NzYxMDAxIiwKICJhdWQiOiAiczZCaGRSa3F0MyIsCiAibm9uY2UiOiAibi0wUzZ
fV3pBMk1qIiwKICJleHAiOiAxMzExMjgxOTcwLAogImlhdCI6IDEzMTEyODA5Nz
AKfQ.ggW8hZ1EuVLuxNuuIJKX_V8a_OMXzR0EHR9R6jgdqrOOF4daGU96Sr_P6q
Jp6IcmD3HP99Obi1PRs-cwh3LO-p146waJ8IhehcwL7F09JdijmBqkvPeB2T9CJ
NqeGpe-gccMg4vfKjkM8FcGvnzZUN4_KSP0aAp1tOJ1zZwgjxqGByKHiOtX7Tpd
QyHE5lcMiKPXfEIQILVq0pcgqeqgeqwhethrDSAdqwwqrt43t3"
}
在返回的时候增加了id_token。
那么问题来了，OAouth2.0 给客户端办法的access token中的Payload中是可以自定义的，并且也可以防篡改，直接把认证的身份信息自定义里多好啊。？或者说，通过access_token去oidc提供的一个endpoint（get/userinfo）去请求用户信息？
原因以下几点:
1)payload里可是明文传输的，增加了传输带宽，也增加了用户信息泄露的风险;
2)access_token本身定义就是授权访问令牌，不关心用户信息，只关心是否能访问，功能耦合;
3)通过endpoint请求用户信息，增加了不少额外的API开销。
下一节，我们会大至说一下.net core服务中基于OAuth2.0和OpenId Connect实现的框架 identiy server 4
