通过一个案例轻松入门OAuth协议

通过一个案例轻松入门OAuth协议

OAuth（Open Authorization）是一个关于授权（authorization）的开放网络标准，允许用户授权第三方应用访问他们存储在另外的服务提供者上的信息，而不需要将用户名和密码提供给第三方移动应用或分享他们数据的所有内容。OAuth在全世界得到广泛应用，目前的版本是 2.0 版。

背景

有一个名为“信用卡管家”（www.a.com）的程序，可以自动从网易云邮箱中读取与信用卡相关的邮件，然后进行分析、汇总后，形成一张报表。

密码

“信用卡管家”如何访问网易云邮箱？

• 用户直接把账号和密码输入，然后“信用卡管家”去读取网易云邮箱的内容

产生的问题？

• 存在信任问题：如果你只是一个小网站，用户不敢把这种很重要的账号和密码信息给你。

token

“信用卡管家”如何访问网易云邮箱？（可见下面整体流程）

• 登录界面提供新的入口，使用网易账号登录。点了之后，就会跳转到网易的认证系统进行登录，然后网易的认证系统需要你输入用户名和密码，并且询问你是否运行”信用卡管家“访问邮箱。
• 确认之后，就重定向到“信用卡管家”网站，并且携带一个token过来，就可以通过API来访问网易邮箱了。
• 整个过程中，不会涉及到用户名和密码。token是网易认证中心颁发的，实际上就代表了用户对信用卡管家访问邮箱的授权，所以有了这个token 就可以访问你的邮箱了
  整体流程

网易怎么信任“信用卡管家”？

• 需要将“信用卡管家”去网易上注册一下，网易就会给“信用卡管家”发一个app_id和app_secret。重定向到网易时就需要将这些东西发过去，这样网易就知道”信用卡管家“这个应用在申请授权了

如何存储这个token？

• 浏览器保存token

• 通过hash fragment的方式，请求的时候带上这个token参数 例如：www.a.com/callback#token=<网易返回的token>”

为什么存储在客户端？

• 为了提高安全性：只会停留在浏览器端， 只有Javascript 能访问它，并且它不会再次通过http request 发到别的服务器器

疑问？图上第6步token以名文方式传输会存在安全问题，可以通过浏览器的历史记录或者访问日志能够获取。

授权码 + token

如何将token进行隐藏？

• 引入了一个叫做Authorization Code的中间层。 当用户用网易账号登录的时候， 网易认证中心这一次不给”信用卡管家“直接发token,而是发一个授权码(authorization code) ,

• 信用卡管家服务器端取到这个code以后，在后台再次访问网易认证中心， 这一次网易认证中心才发给”信用卡管家“真正的token 。

  

为何要这样设计？

• 通过返回的授权码在服务器后台‘偷偷地’完成申请token 的过程， 所以token浏览器端根本就接触不到

code也是明文传输，不也存在安全问题码？

• 授权码和信用卡管家申请的app_id，app_secret关联， 只有信用卡管家发出的token请求， 网易认证中心才认为合法； 还可以让授权码有时间限制，比如5分钟失效，还有可以让授权码只能换一次token, 第二次就不行了

总结

本文讲的其实就是就是OAuth 中的三种认证方式，依次是：

1. Resource Owner Password Credentials Grant(资源所有者密码凭据许可)
2. Implicit Grant(隐式许可)
3. Authorization Code Grant(授权码许可)

还有一种叫做Client credentials ,用的较少，文章没有涉及。

在OAuth中，还有几个术语大家可以理解下：

• 资源所有者 : 就是上文中的用户
• 资源服务器 ：即网易邮箱
• 客户端: 就是上文的信用卡管家
• 授权服务器 ： 即上文的网易认证中心

参考资料：
《码农翻身》