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

一、什么是OAuth？

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

 

二、什么是OAuth2.0?

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

• 授权过程比1.0更简洁
• 全程使用https，保证安全的同时，又省去了1.0中对每个token都要加密的要求
• 2.0针对客户端的各种类型，提出了多种获取访问令牌的途径

三、为什么要用OAuth?

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

• 第三方应用需要存储资源所有者的账号/密码，以便将来再次使用，并且通常会以明文的方式存储。
• 第三方应用能访问资源所有者全部的受保护资源，资源所有者无法约束其访问的期限以及能够访问的资源边界。
• 资源所有者无法单独取消个别第三方应用的访问权限，要么全部允许，要么全部不允许。

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

 

四、进一步理解OAuth2.0

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

• resource owner：资源所有者,通常就是指终端用户。

• resource server：资源服务器,持有受保护的资源，能够捕获请求中的access token。

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

• 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种授权许可类型：

• 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泄露的风险。

• Implicit：隐式

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

• Resource Owner Password Credentials：

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

• 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的授权码许可类型，支持联合登录和单点登录，拥有完整的统一用户中心体系，支持用户登录认证层和缓存层的自定义。其详细的时序图如下：

联合登录时序图：

       

 

单点登录时序图：

ok,本篇就这么多内容啦~，感谢阅读O(∩_∩)O。