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

1、什么是OAuth？

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

 

2、什么是OAuth2.0?

有2.0天然有1.0，相比1.0，2.0有以下不一样：

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

3、为何要用OAuth?

传统的client-server 认证模式下，客户端通常经过资源全部者的帐号/密码，来向服务端请求某个受保护的资源。那么，为了能让第三方应用访问这些受保护的资源，资源全部者可能须要与第三方应用共享本身的帐号/密码，可是这么作存在一些问题：

• 第三方应用须要存储资源全部者的帐号/密码，以便未来再次使用，而且一般会以明文的方式存储。
• 第三方应用能访问资源全部者所有的受保护资源，资源全部者没法约束其访问的期限以及可以访问的资源边界。
• 资源全部者没法单独取消个别第三方应用的访问权限，要么所有容许，要么所有不容许。

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

 

4、进一步理解OAuth2.0

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

• resource owner：资源全部者,一般就是指终端用户。

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

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

• authorization server：受权服务器,负责颁发access token 给client，前提是client已经获取了资源全部者的受权。

       二、协议流示意图

• (1)client请求用户受权以访问资源；
• (2)若是用户受权，client会接收到一个受权许可；
• (3)client凭借受权许可及客户端身份标识，请求access token；
• (4)若是client身份和受权许可都认证经过，受权服务器会颁发令牌；
• (5)client凭借访问令牌到资源服务器请求资源；
• (6)若是访问令牌有效，资源服务器会返回相应资源给client。

三、该协议流是整体概念，实际会根据使用的受权许可的类型不一样而有所差别，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。

 

5、如何实现OAuth2.0？

开源界有不少基于各类语言实现的OAuth2.0的框架，咱们能够根据自身的须要选择符合本身要求的框架，可是颇有可能分析下来，咱们会发现有些语言领域的OAuth2.0框架并不能知足实际的需求。

好比咱们只想实现相似“一处登陆，到处同行(单点登陆)；或者一个账号多处登陆(联合登陆，好比使用QQ、微信账号登陆)”的特性，使用相似Spring Security OAuth就有些过重了(除非你已经再用而且很是熟悉了)，而Apache Oltu又过于粗糙，基本只提供了空架子，还要依赖它的各类包，Light OAuth2却是很轻量，但又和undertow紧耦合，因此自研一套更轻量级的、可扩展的、适用自身业务场景的OAuth2.0框架会显得更合适。

笔者曾花费一些时间自研了一套OAuth2.0的框架，目前只包含OAuth2.0的受权码许可类型，支持联合登陆和单点登陆，拥有完整的统一用户中心体系，支持用户登陆认证层和缓存层的自定义。其详细的时序图以下：

联合登陆时序图：

       

 

单点登陆时序图：

 

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