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

由数据迁移至MongoDB导致的数据不一致问题及解决方案

一、什么是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、协议流示意图
OAuth2.0概念以及实现思路简介

  • (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的授权码许可类型,支持联合登录和单点登录,拥有完整的统一用户中心体系,支持用户登录认证层和缓存层的自定义。其详细的时序图如下:
联合登录时序图:
       OAuth2.0概念以及实现思路简介
 
单点登录时序图:
OAuth2.0概念以及实现思路简介

 

深入 Create React App 核心概念

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

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

Spring Cloud Stream消息驱动@SendTo和消息降级

© 版权声明
THE END
喜欢就支持一下吧
点赞0 分享