浅谈OAuth2.0

程序员麻辣烫

已于 2022-06-01 15:20:36 修改

阅读量3.4k

点赞数 1

分类专栏：架构文章标签：服务器安全 http

于 2022-02-20 14:05:56 首次发布

本文链接：https://blog.csdn.net/shida219/article/details/123030331

版权

架构专栏收录该内容

48 篇文章 16 订阅

订阅专栏

OAuth是一个关于授权（authorization）的开放网络标准，在全世界得到广泛应用，目前的版本是2.0版。OAuth不是一个认证协议，这点不要搞混。

原因

为什么需要OAuth2.0？

资源拥有者（RO）在资源服务器（RS）上存了一些照片，RO想通过客户应用打印这些照片。想访问RS上的照片，必须有用户授权才可以，传统方法是RO将自己在RS上的账号、密码提供给客户应用，然后客户应用就可以访问RS上的资源了。

但这样会有很多问题：

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

OAuth2.0就可以解决这个问题。

设计

OAuth2.0能够基于令牌Token的授权，在无需暴露用户密码的情况下，使应用能够获取对用户数据的有限访问权限。

OAuth2.0主要是增加了一层授权服务器（AS），客户应用最终从授权服务器获取Token，然后使用Token获取资源服务器上的资源。

这样做好处有：

更安全，客户端不接触用户密码
针对Token可以设置寿命、访问权限
资源服务器和授权服务器进行解耦（理论上授权服务器和资源服务器来自同一方）

授权类型

OAuth2.0有四种授权类型。

授权码模式

授权码模式（authorization code）是功能最完整、流程最严密的授权模式。它的特点就是通过客户应用的后台服务器，与资源服务器的认证服务器进行互动。

交互图为：

假设用户想通过浏览器，使用云打印功能，打印资源服务器里的照片。用户通过浏览器在云打印应用上发起打印请求，云打印发现自己没有权限访问，返回302让用户先授权，该请求最终转发到授权服务器上，授权服务器会要求用户输入账号密码，用户输入完成后，给客户应用授予限定权限。授权服务器生成的code会根据最初请求中提供的redirect_uri到云打印应用，这样客户应用就能获取到code。云打印应用使用code去授权服务器获取token，获得后用便可使用该token去资源服务器获取指定资源。

简化模式

简化模式（implicit grant type）不通过第三方应用程序的服务器，直接在浏览器中向认证服务器申请令牌，跳过了"授权码"这个步骤，因此得名。所有步骤在浏览器中完成，令牌对访问者是可见的，且客户端不需要认证。

简化模式和授权码模式相比，不再使用授权码，User-Agent（浏览器）也能知道Token值，增加了风险。

密码模式

密码模式（Resource Owner Password Credentials Grant）中，用户向客户端提供自己的用户名和密码。客户端使用这些信息，向"服务商提供商"索要授权。

在这种模式中，用户必须把自己的密码给客户端，但是客户端不得储存密码。这通常用在用户对客户端高度信任的情况下，比如客户端是操作系统的一部分，或者由一个著名公司出品。而认证服务器只有在其他授权模式无法执行的情况下，才能考虑使用这种模式。

客户端模式

客户端模式（Client Credentials Grant）指客户端以自己的名义，而不是以用户的名义，向"服务提供商"进行认证。严格地说，客户端模式并不属于OAuth框架所要解决的问题。在这种模式中，用户直接向客户端注册，客户端以自己的名义要求"服务提供商"提供服务，其实不存在授权问题。这种模式一般用于内部服务器之间通信。