微服务系列之授权认证(一) OAuth 2.0 和 OpenID Connect

时间：2022-09-15 19:46:06

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

　　微服务系列之授权认证(一) OAuth 2.0 和 OpenID Connect

(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

　　

　　

 

相关文章