Auth2.0 学习录

最新推荐文章于 2024-08-01 09:58:08 发布

lajimei1990

最新推荐文章于 2024-08-01 09:58:08 发布

阅读量450

点赞数

分类专栏： Android 文章标签： android

Android 专栏收录该内容

0 篇文章 0 订阅

订阅专栏

Auth2.0 框架图

引用网上其他资料的一张经典截图：

看下图所示：

图(1)

(1) Client初始化协议的执行流程。首先通过HTTP 302来重定向RO用户代理到AS。Client在redirect_uri中应包含如下参数：client_id, scope (描述被访问的资源), redirect_uri (即Client的URI), state (用于抵制CSRF攻击). 此外，请求中还可以包含access_type和approval_prompt参数。当approval_prompt=force时，AS将提供交互页面，要求RO必须显式地批准（或拒绝）Client的此次请求。如果没有approval_prompt参数，则默认为RO批准此次请求。当access_type=offline时，AS将在颁发access_token时，同时还会颁发一个refresh_token。因为access_token的有效期较短（如3600秒），为了优化协议执行流程，offline方式将允许Client直接持refresh_token来换取一个新的access_token。

(2) AS认证RO身份，并提供页面供RO决定是否批准或拒绝Client的此次请求（当approval_prompt=force时）。

(3) 若请求被批准，AS使用步骤(1)中Client提供的redirect_uri重定向RO用户代理到Client。redirect_uri须包含authorization_code，以及步骤1中Client提供的state。若请求被拒绝，AS将通过redirect_uri返回相应的错误信息。

(4) Client拿authorization_code去访问AS以交换所需的access_token。Client请求信息中应包含用于认证Client身份所需的认证数据，以及上一步请求authorization_code时所用的redirect_uri。

(5) AS在收到authorization_code时需要验证Client的身份，并验证收到的redirect_uri与第3步请求authorization_code时所使用的redirect_uri相匹配。如果验证通过，AS将返回access_token，以及refresh_token（若access_type=offline）

图(1)

图中Alice`s Web Brower 作为典型的RO(Resource owner) ， Facebook.com对应Client ， Google Authorization Server 对应AS ， Google Resource Server对应RS 。

第一步：图中Facebook.com检测到Alice`s 没有登录将告知REDIRECT_URL 然后由Alice`s Web Browser去打开这个链接，也就是AS认证授权界面。

第二步：如果授权失败那么将停留在授权界面或者返回到Alice`s Web Browser界面不做动作，知道他再次通过登录方式成功也即对应上面的第二部

第三步：如果授权成功那么返回到Alice`s Web Browser界面会在URL中带上参数，这里重要参数是code 值。Alice`s Web Browser带上Code重新访问Facebook.com

第四步： Facebook.com 会用code以post方式请求AS拿到临时令牌 (Access token) ，

第五步： AS 将临时令牌和其他信息反馈给Facebook.com 。

第六步： Facebook.com 会用令牌去RS取对应的数据。

读者请注意，在步骤(4)中，Client需要拿“授权码”去换“授权令牌”时，Client需要向AS证明自己的身份，即证明自己就是步骤(2)中Alice批准授权时的Grantee。这个身份证明的方法主要有两种（图3中使用了第1种）：
(1) 通过https直接将client_secret发送给AS，因为client_secret是由Client与AS所共享，所以只要传送client_secret的信道安全即可。
(2) 通过消息认证码来认证Client身份，典型的算法有HMAC-SHA1。在这种方式下，Client无需传送client_secret，只需发送消息请求的signature即可。由于不需要向AS传递敏感数据，所以它只需要使用http即可。

此外，在步骤(2)中，Google授权服务器需要认证Alice的RO身份，并提供授权界面给Alice进行授权审批。今天Google提供的实例如图4、图5所示，仅供读者理解OAuth这种“现场授权”或"在线授权"的含义。

提问
1. 为何引入authorization_code？

          协议设计中，为什么要使用authorization_code来交换access_token？这是读者容易想到的一个问题。也就是说，在协议的第3步，为什么不直接将access_token通过重定向方式返回给Client呢？比如:
          HTTP/1.1 302
          Location:
         https://www.facebook.com/?access_token=ya29.AHES6ZSXVKYTW2VAGZtnMjD&token_type=Bearer&expires_in=3600
         如果直接返回access_token，协议将变得更加简洁，而且少一次Client与AS之间的交互，性能也更优。那为何不这么设计呢？协议文档[1]中并没有给出这样设计的理由，但也不难分析：

     (1) 浏览器的redirect_uri是一个不安全信道，此方式不适合于传递敏感数据（如access_token）。因为uri可能通过HTTP referrer被传递给其它恶意站点，也可能存在于浏览器cacher或log文件中，这就给攻击者盗取access_token带来了很多机会。另外，此协议也不应该假设RO用户代理的行为是可信赖的，因为RO的浏览器可能早已被攻击者植入了跨站脚本用来监听access_token。因此，access_token通过RO的用户代理传递给Client，会显著扩大access_token被泄露的风险。但authorization_code可以通过redirect_uri方式来传递，是因为authorization_code并不像access_token一样敏感。即使authorization_code被泄露，攻击者也无法直接拿到access_token，因为拿authorization_code去交换access_token是需要验证Client的真实身份。也就是说，除了Client之外，其他人拿authorization_code是没有用的。此外，access_token应该只颁发给Client使用，其他任何主体（包括RO）都不应该获取access_token。协议的设计应能保证Client是唯一有能力获取access_token的主体。引入authorization_code之后，便可以保证Client是access_token的唯一持有人。当然，Client也是唯一的有义务需要保护access_token不被泄露。

     (2) 引入authorization_code还会带来如下的好处。由于协议需要验证Client的身份，如果不引入authorization_code，这个Client的身份认证只能通过第1步的redirect_uri来传递。同样由于redirect_uri是一个不安全信道，这就额外要求Client必须使用数字签名技术来进行身份认证，而不能用简单的密码或口令认证方式。引入authorization_code之后，AS可以直接对Client进行身份认证（见步骤4和5），而且可以支持任意的Client认证方式（比如，简单地直接将Client端密钥发送给AS）。

       在我们理解了上述安全性考虑之后，读者也许会有豁然开朗的感觉，懂得了引入authorization_code的妙处。那么，是不是一定要引入authorization_code才能解决这些安全问题呢？当然不是。笔者将会在另一篇博文给出一个直接返回access_token的扩展授权类型解决方案，它在满足相同安全性

       的条件下，使协议更简洁，交互次数更少。

2.   基于Web安全的考虑

       OAuth协议设计不同于简单的网络安全协议的设计，因为OAuth需要考虑各种Web攻击，比如CSRF (Cross-Site Request Forgery), XSS (Cross Site Script), Clickjacking。要理解这些攻击原理，读者需要对浏览器安全（eg, Same Origin Policy, 同源策略）

       有基本理解。比如，在redirect_uri中引入state参数就是从浏览器安全角度考虑的，有了它就可以抵制CSRF攻击。如果没有这个参数，攻击者便可以在redirect_uri中注入攻击者提供的authorization_code或access_token，结果可能导致Client访问错误的资源

      （比如，将款项汇到一个错误的帐号）。

Auth2.0 token保存与session会话

1. token 保存：如果Client将token交给了RO, 那么RO可以将这个管理起来，保存到sqlite 或者 sharepreference 中。（保存token值与时间戳）如果下次登录没有检测到token值那么将走上面的auth2.0认证流程，如果有token值，那么需要判断

是否取出来的时间戳与保存的时间戳超过有效时间范围，如果没有超过那么可以直接利用token做后面的事情不用登录认证。如果失效了，那么需要重新更新令牌。

2. 令牌更新：如果检测到需要更新令牌需要通过Client 更新， Client拿到旧的令牌跟AS 认证中心更新令牌。

3. session 维持：在RO 拿到code值对Client发起请求时维持session ，在android端维持session使用单例HttpClient对象可以自动维护。如果需要手动维护需要在HttpClient中加入Cookie , Cookie 保存session Id与session 有效时间。