OAuth2.0概念以及实现思路简介

Posted 2021-04-24 擎天软件

OAuth是一个关于授权（authorization）的开放网络标准，在全世界得到广泛应用，目前的版本是2.0版。本文的初衷是通过对OAuth 2.0的剖析，帮助您更好地理解OAuth。

什么是OAuth？

OAuth 是一个授权规范，可以使A应用在受限的情况下访问B应用中用户的资源(前提是经过了该用户的授权，而A应用并不需要也无法知道用户在B应用中的账号和密码)，资源通常以REST API的方式暴露。

什么是OAuth2.0?

有2.0自然有1.0，相比1.0，2.0有如下不同：

1、授权过程比1.0更简洁；

2、全程使用https，保证安全的同时，又省去了1.0中对每个token都要加密的要求；

3、2.0针对客户端的各种类型，提出了多种获取访问令牌的途径。

为什么要用OAuth?

传统的client-server 认证模式下，客户端一般通过资源所有者的账号/密码，来向服务端请求某个受保护的资源。那么，为了能让第三方应用访问这些受保护的资源，资源所有者可能需要与第三方应用共享自己的账号/密码，但是这么做存在一些问题：

1、第三方应用需要存储资源所有者的账号/密码，以便将来再次使用，并且通常会以明文的方式存储；

2、第三方应用能访问资源所有者全部的受保护资源，资源所有者无法约束其访问的期限以及能够访问的资源边界；

3、资源所有者无法单独取消个别第三方应用的访问权限，要么全部允许，要么全部不允许。

而OAuth 可以解决这些问题，方法是引入一个授权层，并且将客户端与资源所有者的角色分离。OAuth下，客户端可以访问哪些资源受资源所有者控制，并且客户端的访问凭证与资源所有者是不同的。客户端不再使用资源所有者的凭证访问受保护的资源，而是通过获取一个access token（一个字符串，能够表 示访问的边界，访问的期限等访问属性）。在经过用户授权后，access token会由一个授权服务器发布给第三方客户端。然后，第三方客户端使用access token到资源服务器访问受保护的资源。

进一步理解OAuth2.0

1、OAuth中涉及的几个角色：

（1）resource owner：资源所有者，通常就是指终端用户；

（2）resource server：资源服务器，持有受保护的资源，能够捕获请求中的access token；

（3）client：第三方应用，需访问资源所有者受保护资源的应用。“client”在auth中只是一个术语，统指第三方应用，与该应用的执行是在服务器，桌面或其它设备上无关；

（4）authorization server：授权服务器，负责颁发access token 给client，前提是client已经获取了资源所有者的授权。

2、协议流示意图

（1）client请求用户授权以访问资源；

（2）如果用户授权，client会接收到一个授权许可；

（3）client凭借授权许可及客户端身份标识，请求access token；

（4）如果client身份和授权许可都认证通过，授权服务器会颁发令牌；

（5）client凭借访问令牌到资源服务器请求资源；

（6）如果访问令牌有效，资源服务器会返回相应资源给client。

3、该协议流是总体概念，实际会根据使用的授权许可的类型不同而有所差异，OAuth2.0有4种授权许可类型：

（1）Authorization Code：授权码

        授权码从授权服务器获得，授权服务器充当client和resource owner的中间者。client不会直接从Resource Owner请求授权，而是引导Resource Owner到授权服务器，授权服务器会反向引导Resource Owner至client，并带上授权码。返回授权码之前，由授权服务器验证Resource Owner的身份以及授权情况，因为ResourceOwner只会在授权服务器做认证，Resource Owner的凭证信息是不会让client知晓的。授权码在安全方面带来了一些重要的好处，比如对客户端认证的能力，以及避免了直接通过Resource Owner的user-agent(比如浏览器)来传输access token，使得access token对其他人不可见，包括Resource Owner自己，大大降低了access token泄露的风险；

（2）Implicit：隐式

Implicit许可类型是针对clients简化过的授权码许可类型，在浏览器利用脚本语言来实现。使用Implicit类型，用户授权后，client直接获取一个access token，而不是获取一个授权码。由于没有像授权码一样的中间凭证产生，所以授权许可是隐式的。由于这种特性，在某些使用浏览器进行URI重定向的场景下，access token可能会暴露。Implicit改善了一些clients的响应效率，但是也带来了安全隐患，所以建议一般只在Mobile Apps等不那么容易从URI中获取信息的应用中并且授权码类型不可用的场景下使用；

（3）Resource Owner Password Credentials：

直接使用资源所有者的密码凭证(比如：用户名和密码)作为授权许可来获取access token。该类型下虽然client知晓了Resource Owner的凭证，但是可以通过换取一个长生命周期的access token或 refresh token 来避免长期存储凭证以便将来再次使用的需要。但是除非client是被高度受信任的，并且授权码类型不能使用的场景，否则不建议使用；

（4）Client Credentials

客户端凭证(或其它的认证形式)可以直接用作授权许可。适用于授权边界不需要Resource Owner控制或者能够在授权服务器预先配置的场景，比如在多个资源服务器共用统一用户中心的场景下，资源服务器之间需要相互访问，此时client可能也是resource owner 或者resource server。

如何实现OAuth2.0？

开源界有很多基于各种语言实现的OAuth2.0的框架，我们可以根据自身的需要选择符合自己要求的框架，但是很有可能分析下来，我们会发现有些语言领域的OAuth2.0框架并不能满足实际的需求。

比如我们只想实现类似使用QQ、微信、微博账号登录的服务特性，使用类似Spring Security OAuth就有些太重磅了(除非你已经在用并且非常熟悉了)，而Apache Oltu又过于粗糙，基本只提供了空架子，还要依赖其它的各种包，新进的Light OAuth2倒是很轻量，但又和undertow紧耦合，所以此时，自研一套轻量级的、可扩展的、适用自身业务场景的OAuth2.0框架会显得更合适。

笔者曾花费一些时间自研了一套OAuth2.0的框架，目前只包含OAuth2.0的授权码许可类型，并支持用户登录认证层和缓存层的自定义。其详细的时序图如下：  

虽然2.0版本的OAuth还处于draft阶段，但是有很多公司已经采用了，希望这篇文章对您有帮助。