OAuth 2.0

OAuth是一个关于授权（authorization）的开放网络标准，在全世界得到广泛应用，目前的版本是2.0版。

最近小组B.L.前辈share了oauth的一些知识，为了巩固我贫瘠丰富的知识储备，趁摸鱼空闲的时间，复习一下

本文将对OAuth 2.0做一个简单的介绍，主要参考材料为RFC 6749和阮一峰的网络日志和go4it

OAuth产生的背景

任何身份的认证，基本都是基于对请求方的不信任产生的

如果一个用户拥有两项服务：一项服务是图片在线存储服务A，另一个是图片在线打印服务B。如下图所示。由于服务A与服务B是由两家不同的服务提供商提供的，所以用户在这两家服务提供商的网站上各自注册了两个用户，假设这两个用户名各不相同，密码也各不相同。
当用户要使用服务B打印存储在服务A上的图片时，用户该如何处理？
法一：用户可能先将待打印的图片从服务A上下载下来并上传到服务B上打印，这种方式安全但处理比较繁琐，效率低下
法二：用户将在服务A上注册的用户名与密码提供给服务B，服务B使用用户的帐号再去服务A处下载待打印的图片，这种方式效率是提高了，但是有如下几个缺陷：

（1）B为了后续的服务，会保存用户的密码，这样很不安全。
（2）A不得不部署密码登录，而我们知道，单纯的密码登录并不安全。
（3）B拥有了获取用户储存在A所有资料的权力，用户没法限制B获得授权的范围和有效期。
（4）用户只有修改密码，才能收回赋予B的权力。但是这样做，会使得其他所有获得用户授权的第三方应用程序全部失效。
（5）只要有一个第三方应用程序被破解，就会导致用户密码泄漏，以及所有被密码保护的数据泄漏。

图片地址

OAuth的作用

让客户端（服务B）安全可控地获取用户的授权，与服务提供商（服务A）之间进行交互
既免去了用户同步的麻烦，又增加了信息的安全性

OAuth的思路

OAuth在"客户端"与"服务提供商"之间设置一个授权层（authorization layer）
“客户端"不能直接登录"服务提供商”，只能登录授权层，以此将用户与客户端区分开来
"客户端"登录授权层所用的令牌（token），与用户的密码不同
用户可以在登录的时候，指定授权层令牌的权限范围和有效期
"客户端"登录授权层以后，"服务提供商"根据令牌的权限范围和有效期，向"客户端"开放用户储存的资料。

运行流程

图取自摘自RFC 6749
运行流程
其中B步骤，用户同意给予客户端授权是关键

OAuth 2.0 授权方式

密码模式（resource owner password credentials）
- 这种模式是最不推荐的，因为 client 可能存了用户密码
  这种模式主要用来做遗留项目升级为 oauth2 的适配方案
  当然如果 client 是自家的应用，也是可以
  支持 refresh token
授权码模式（authorization code）
- 这种模式算是正宗的oauth2的授权模式
  设计了auth code，通过这个code再获取token
  支持refresh token
简化模式（implicit）
- 这种模式比授权码模式少了code环节，回调url直接携带token
  这种模式的使用场景是基于浏览器的应用
  这种模式基于安全性考虑，建议把token时效设置短一些
  不支持refresh token
客户端模式（client credentials）
- 这种模式直接根据client的id和密钥即可获取token，无需用户参与
  这种模式比较合适消费api的后端服务，比如拉取一组用户信息等
  不支持refresh token，主要是没有必要

我们主要了解授权码模式就好，这是目前最广泛的方式
授权码模式

下一篇将主要了解授权码模式是如何运作的，以及它的例子
THE END

欢迎小白们互相交流与沟通
欢迎大神们鞭策批评与指导

作者： Murphy

OAuth 2.0介绍（一）