微服务系列之授权认证(一) 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