• 浅谈Oauth2.0授权


    一、背景

    近期公司准备上身份认证平台(IAM),主要有两块内容,一部分是单点登录、一部分是账号生命周期管理。其中涉及几个常用的单点登录标准认证协议,其中有SMAL、LOAP、CAS、OIDC、Oauth2.0,本篇文章对Oauth2.0认证协议进行讲解。

    二、Oauth发展史

    OAuth的发展史可以分为以下几个阶段:
    2007年12月,OAuth 1.0版本发布,并迅速成为工业标准。
    2008年6月,发布了OAuth 1.0 Revision A,这是一个稍作修改的修订版本,主要修正了一个安全方面的漏洞。
    2010年4月,OAuth 1.0在IETF发布,协议编号RFC 5849。
    2010年,发布了OAuth 2.0,这是OAuth协议的下一个版本,该版本与OAuth 1.0不兼容。

    OAuth 诞生之初是为了解决 Web 浏览器场景下的授权问题。比如有一个网站A,在新用户注册时是支持QQ账号注册的,如果网站A能拿到QQ昵称和头像作为网站A用户注册的基本资料,这样新注册用户流程就简单多了,很多信息都不需要用户自己填写,直接套用QQ号的信息就可以了。这样的注册模式就对用户很友好,自然很容易提升用户注册的热情。 

    三、Oauth2.0定义

    OAuth 2.0一词中的"Auth"表示"授权Authorization",字母"O"表示"开放Open",连在一起就表示"开放授权"。这也是为什么我们使用OAuth的场景,通常发生在开放平台的环境下。首先需要区分下认证和授权:

    • 认证(Authentication):用来验证某个用户是否具有访问系统的权限。如果认证通过,该用户就可以访问系统,从而创建、修改、删除、查询平台支持的资源。认证的方式就是我们登录,比如账密登录、手机验证码登录等。
    • 授权(Authorization):用来验证某个用户是否具有访问某个资源的权限,如果授权通过,该用户就能对资源做增删改查等操作。

    简单而言,认证就是证明访问者的身份,决定他是否能进入系统;授权则是决定访问者能做哪些内容。一般来说,都是先认证后检查授权。

    四、Oauth2.0常用角色

    OAuth 2.0 主要有4类角色:

        resource owner:资源所有者,指终端的“用户”(即授权登录中资料信息的拥有者)。
        resource server:资源服务器,即服务提供商存放受保护资源。访问这些资源,需要获得访问令牌(access token)。
        client:客户端,代表向受保护资源进行资源请求的第三方应用程序。
        authorization server: 授权服务器, 在验证资源所有者并获得授权成功后,将发放访问令牌给客户端。

    五、Oauth2.0常用模式

    OAuth2.0提供了四种授权(获取令牌)方式,四种方式均采用不同的执行流程,让我们适应不同的场景。

    • 授权码(authorization-code)
    • 隐藏式(implicit)
    • 密码式(password):
    • 客户端凭证(client credentials)

    5.1、授权码(authorization-code)--最广泛

    授权码authorization code)方式,指的是第三方应用先申请一个授权码,然后再用该码获取令牌。这种方式是最常用的流程,安全性也最高,它适用于那些有后端的 Web 应用。授权码通过前端传送,令牌则是储存在后端,而且所有与资源服务器的通信都在后端完成。这样的前后端分离,可以避免令牌泄漏。

    重要步骤说明

    第一步,A 网站提供一个链接,用户点击后就会跳转到 B 网站,授权用户数据给 A 网站使用。下面就是 A 网站跳转 B 网站的一个示意链接。

    1. https://b.com/oauth/authorize?
    2. response_type=code&
    3. client_id=CLIENT_ID&
    4. redirect_uri=CALLBACK_URL&
    5. scope=read

    上面 URL 中,response_type参数表示要求返回授权码(code),client_id参数让 B 知道是谁在请求,redirect_uri参数是 B 接受或拒绝请求后的跳转网址,scope参数表示要求的授权范围(这里是只读)。 

    第二步,用户跳转后,B 网站会要求用户登录,然后询问是否同意给予 A 网站授权。用户表示同意,这时 B 网站就会跳回redirect_uri参数指定的网址。跳转时,会传回一个授权码,就像下面这样。下面 URL 中,code参数就是授权码。 

    https://a.com/callback?code=AUTHORIZATION_CODE

    第三步,A 网站拿到授权码以后,就可以在后端,向 B 网站请求令牌。

    1. https://b.com/oauth/token?
    2. client_id=CLIENT_ID&
    3. client_secret=CLIENT_SECRET&
    4. grant_type=authorization_code&
    5. code=AUTHORIZATION_CODE&
    6. redirect_uri=CALLBACK_URL

    上面 URL 中,client_id参数和client_secret参数用来让 B 确认 A 的身份(client_secret参数是保密的,因此只能在后端发请求),grant_type参数的值是AUTHORIZATION_CODE,表示采用的授权方式是授权码,code参数是上一步拿到的授权码,redirect_uri参数是令牌颁发后的回调网址。

    第四步,B 网站收到请求以后,就会颁发令牌。具体做法是向redirect_uri指定的网址,发送一段 JSON 数据。

    1. {
    2. "access_token":"ACCESS_TOKEN",
    3. "token_type":"bearer",
    4. "expires_in":2592000,
    5. "refresh_token":"REFRESH_TOKEN",
    6. "scope":"read",
    7. "uid":100101,
    8. "info":{...}
    9. }

    上面 JSON 数据中,access_token字段就是令牌,A 网站在后端拿到了。

    5.2、隐藏式(implicit)

    有些 Web 应用是纯前端应用,没有后端。这时就不能用上面的方式了,必须将令牌储存在前端。RFC 6749 就规定了第二种方式,允许直接向前端颁发令牌。这种方式没有授权码这个中间步骤,所以称为(授权码)"隐藏式"(implicit)。这种方式把令牌直接传给前端,是很不安全的。因此,只能用于一些安全要求不高的场景,并且令牌的有效期必须非常短,通常就是会话期间(session)有效,浏览器关掉,令牌就失效了。

    第一步,A 网站提供一个链接,要求用户跳转到 B 网站,授权用户数据给 A 网站使用。下面 URL 中,response_type参数为token,表示要求直接返回令牌。

    1. https://b.com/oauth/authorize?
    2. response_type=token&
    3. client_id=CLIENT_ID&
    4. redirect_uri=CALLBACK_URL&
    5. scope=read

     第二步,用户跳转到 B 网站,登录后同意给予 A 网站授权。这时,B 网站就会跳回redirect_uri参数指定的跳转网址,并且把令牌作为 URL 参数,传给 A 网站。下面 URL 中,token参数就是令牌,A 网站因此直接在前端拿到令牌。

    https://a.com/callback#token=ACCESS_TOKEN

    5.3、密码式(password)

    如果高度信任第三方应用,RFC 6749 也允许用户把用户名和密码,直接告诉该应用。该应用就使用你的密码,申请令牌,这种方式称为"密码式"(password)。这种方式需要用户给出自己的用户名/密码,显然风险很大,因此只适用于其他授权方式都无法采用的情况,而且必须是用户高度信任的应用。

    第一步,A 网站要求用户提供 B 网站的用户名和密码。拿到以后,A 就直接向 B 请求令牌。下面 URL 中,grant_type参数是授权方式,这里的password表示"密码式",usernamepassword是 B 的用户名和密码。

    1. https://oauth.b.com/token?
    2. grant_type=password&
    3. username=USERNAME&
    4. password=PASSWORD&
    5. client_id=CLIENT_ID

    第二步,B 网站验证身份通过后,直接给出令牌。注意,这时不需要跳转,而是把令牌放在 JSON 数据里面,作为 HTTP 回应,A 因此拿到令牌。

    5.4、客户端凭证(client credentials)

    client credentials通常适用于没有前端的命令行应用。例如系统之间的接口交互认证,例如:适用于A系统请求B系统的后端需要认证场景。这种方式给出的令牌,是针对第三方应用的,而不是针对用户的。

    第一步,A 应用在命令行向 B 发出请求。下面 URL 中,grant_type参数等于client_credentials表示采用凭证式,client_idclient_secret用来让 B 确认 A 的身份。

    1. https://oauth.b.com/token?
    2. grant_type=client_credentials&
    3. client_id=CLIENT_ID&
    4. client_secret=CLIENT_SECRET

    第二步,B 网站验证通过以后,直接返回令牌。 

    1. {
    2. "access_token":"ACCESS_TOKEN",
    3. "token_type":"bearer",
    4. "expires_in":2592000,
    5. "refresh_token":"REFRESH_TOKEN",
    6. "scope":"read",
    7. "uid":100101,
    8. "info":{...}
    9. }

    六、Oauth2.0最佳实践(授权码模式)

    让我们看下业界标杆微信开放平台是怎么做开放授权的。网站应用微信登录是基于OAuth2.0协议标准构建的微信OAuth2.0授权登录系统,微信OAuth2.0授权登录目前支持authorization_code模式。

    流程步骤

    1. 网站A需要在微信开放平台注册,填写回调地址,并获得相应的 AppID 和AppSecret。
    2. 用户登录了网站A,获得了网站A的登录态,这里用JWT来维护登录态。
    3. 此时网站A需要访问用户的微信相关资源,这里需要获得用户的微信授权。网站A弹出一个页面引导用户去微信开放平台的网站来授权。
    4. 用户点击【去授权】,浏览器跳转到微信二维码界面。
    5. 此时微信用户尚未在web端登录,因此需要微信用户【扫码登录】,登录成功后浏览器带着AppID请求微信开放平台,请求授权给网站A。
    6. 微信开放平台同意后返回页面让微信用户确认:网站A将获取以下权限:1. ... 2. ...,是否同意授权。
    7. 点击【同意授权】,用户浏览器就带着AppID和重定向URI两个参数去请求微信开放平台的授权服务器。重定向URI是网站A的地址。
    8. 微信开放平台的授权服务器收到请求,通过AppID知道了这个是要微信用户要给网站A授权,因此生成了一个授权码CODE,以重定向的方式返回给微信用户,重定向的地址填的是第7步请求带上来的URI,并参数带上这个CODE。
    9. 微信用户收到重定向的回复后,拿出重定向URI和CODE,重定向跳转到这个URI,并参数带上这个CODE。因为跳转的网址是网站A的域名地址,因为用户已经在该网站登录了,因此这个请求会带上登录态的JWT。
    10. 网站A收到微信用户CODE后,从JWT中解析出这个请求的来源用户的uid,这样网站用户uid就跟CODE有了绑定关系。接着拿出自己的AppID 和AppSecret,跟CODE一起请求微信开放平台授权服务器。
    11. 微信开放平台授权服务器收到AppID + AppSecre + CODE 三个参数后,生成access_token、refresh_token,返回这些token给网站A。
    12. 网站A拿到access_token后就存储起来,有了uid->access_token的映射关系。后续带着这个access_token就可以访问微信用户的指定资源了,无需每次要微信用户登录和授权。

    七、Oauth2.0令牌使用和更新

    7.1、令牌使用

    A 网站拿到令牌以后,就可以向 B 网站的 API 请求数据了。每个发到 API 的请求,都必须带有令牌。具体做法是在请求的头信息,加上一个Authorization字段,令牌就放在这个字段里面。下面命令中,ACCESS_TOKEN就是拿到的令牌。

    curl -H "Authorization: Bearer ACCESS_TOKEN"

    "https://api.b.com"

    7.2、更新令牌

    令牌的有效期到了,如果让用户重新走一遍上面的流程,再申请一个新的令牌,很可能体验不好,而且也没有必要。OAuth 2.0 允许用户自动更新令牌。 具体方法是,B 网站颁发令牌的时候,一次性颁发两个令牌,一个用于获取数据,另一个用于获取新的令牌(refresh token 字段)。令牌到期前,用户使用 refresh token 发一个请求,去更新令牌。

    1. https://b.com/oauth/token?
    2. grant_type=refresh_token&
    3. client_id=CLIENT_ID&
    4. client_secret=CLIENT_SECRET&
    5. refresh_token=REFRESH_TOKEN

    上面 URL 中,grant_type参数为refresh_token表示要求更新令牌,client_id参数和client_secret参数用于确认身份,refresh_token参数就是用于更新令牌的令牌。 B 网站验证通过以后,就会颁发新的令牌。

    refresh_token拥有较长的有效期(30天),当refresh_token失效后,需要用户重新授权。因为access_token是需要频繁在网络上传输的,因此被窃取的风险大,所access_token的有效时间设置较短;refresh_token仅仅在续签access_token时会在网络上传输,被窃取的风险相对小点,因此refresh_token拥有较长的有效期。这样一长一短的双token机制会比较安全。

    双Token机制更为安全,而且可以很好的处理在线、离线续签的问题,可以参考这个回答深入理解双Token机制。如下图:

  • 相关阅读:
    nginx日志分割
    go语言中的文件file操作
    记于2022.7.21
    抖音面试:说说延迟任务的调度算法?
    【精选】自学网络安全的三个必经阶段(含路线图)
    极狐GitLab 如何重置管理员密码
    基于Spring Boot的房屋租赁系统
    算法练习1——合并两个有序数组
    postman定义公共函数这样写,测试组长直呼牛逼!!!
    十全十美源码
  • 原文地址:https://blog.csdn.net/juanxiaseng0838/article/details/132756575