OAuth2.0 看这篇就够了

拥有多年百强外企研发实验室工作经验,目前就职于某独角兽创业公司。全栈开发工程师。做过C,C++,Java,C#,Python,Jquery Mobile,Hybrid App,Android开发,主要擅长 Java 分布式系统设计与研发。 欢迎关注我的个人公众号: hacker_nick,一起探讨学习,攻克面试。

文章正文

随着互联网技术的发展,微服务架构已经成为每个互联网公司的标配。伴随着服务粒度的细化,服务的安全和鉴权问题,以及客户端与服务之间的认证问题已经成为必不可少的一项工作。说起认证和鉴权,那怎么少得了 OAuth 2.0 协议呢?

火锅店旁边的照片打印机

这个案例想必大家都遇到过,在商场里面或者餐馆门口会看到一些可以打印照片的设备。想要设备打印出照片那么必须传输照片给设备,但是假如此时由于你的手机设备存储有限,美美的照片被存储在了百度云盘。那么如何让设备获取到你存储在云盘的照片呢?聪明的你肯定已经想到对策了。

1. 账户和密码

这种方式最为简单直接,但是一旦你将账户和密码告诉第三种应用,第三方应用就会无所不能,随意操作你的账户不受你的管控。你唯一能做的就是更改掉旧的密码,这样才能收回你的权限。

2. 开发者钥匙

这种方式需要先在资源提供方申请开发者钥匙,它建立在客户应用和资源方是互相信任的情况下。但是这种方式也会存在开发者钥匙泄露的情况,一旦泄露给不法分子,安全同样会受到威胁。

3. 特殊令牌

这种方式是资源方提供一个令牌给客户应用,通过令牌,客户应用可以访问资源。但是资源方颁发的令牌会受到权限的控制,并且会在有效期终止后自动销毁。

上述特殊令牌的方式即为我们今天即将要讨论的 OAuth 2.0,OAuth 2.0 会解决令牌涉及到的一系列问题。那么 OAuth 2.0 的令牌可以用来解决哪些问题呢?

开放系统间的授权

1. 社交联合登录

想必你在登录一个网站或者应用时候,一定遇到可以通过第三方的应用账户登录的案例。例如你在给一些技术博客做评论的时候需要登录,你又没有该博客的账户,但是你可以通过 GitHub 账户登录然后评论。

2. 开放接口平台

还是 GitHub 的例子,你不但可以直接去 GitHub 的网站上操作账户,你也可以通过 GitHub 提供的开放 API 来操作你的 GitHub 账户。有兴趣可以去了解一下:GitHub API

微服务安全问题

微服务将应用拆成多个小的应用接口服务,但是各个服务之间的业务难免会有所依赖,此时服务之间的调用也需要有安全的保证。同时客户端的接入也会变得复杂,例如:单页面应用、原生应用、Web App 等。这些应用的接入都需要得到安全保证,OAuth 2.0 可以帮助我们解决这些问题。

内部应用授权

企业内部应用繁多,例如代码平台、应用发布平台、OA 系统等。如果为这些系统分别都创建一个账户,那么这对我们员工来说将是一个灾难,我们要记住每个账户和密码,每个系统都需要分别登录。因此有点规模的企业都需要一套单点登录的服务,我们可以通过 OAuth 2.0 来实现企业级的 SSO(单点登录) 服务。

初步认识 OAuth 2.0

如下图所示,OAuth 2.0 中包含四个重要的参与者:资源拥有者、客户应用、受保护资源、授权服务器。下面我们就详细说说 OAuth 2.0 的工作流程,它主要分为以下几个步骤:

在这里插入图片描述

  1. 首先资源拥有者在客户应用中发起对受保护资源的访问请求。
  2. 客户应用向资源服务器发起授权请求。
  3. 资源拥有者通过客户应用代理授予客户应用访问资源的权限。
  4. 授权服务器得到资源拥有者的指令,向客户应用颁发访问令牌。
  5. 客户应用获得受限的权限令牌,访问受保护的资源。

如上几个步骤即为 OAuth 2.0 的主要工作流程。当然其中还有少许细节,客户应用在获得令牌后,第二次访问资源就可以直接使用第一次获取的令牌来访问,无需再次获取。当然令牌也会过期,过期后客户应用需要重新获取授权,这是不是听起来很麻烦呢?OAuth 2.0 支持刷新令牌,即客户应用在令牌过期后,可以直接使用刷新令牌获得新的令牌,这样就省去了重新授权的复杂过程。

OAuth2 到底是什么

定义

上面我们介绍了 OAuth 2.0 的应用场景,以及它的工作流程,是时候来给出 OAuth 2.0 的定义了。

OAuth 2.0 是一个基于令牌 Token 的授权协议,通过它我们可以在不暴露账户和密码的情况下授予客户应用有限的数据访问权限。它解藕了认证和授权,同时它是事实上的安全框架,它能支持服务与服务,App、单页面应用与后端服务等很多应用场景。

授权模式

OAuth 2.0 共有如下四种授权模式,通过下面的任意一种方式,客户应用都可以获得授权令牌来访问受保护的资源。

授权码模式

这种方式是最复杂但也是最安全的方式。资源所有者授予客户应用访问权限后,授权服务器首次发放给客户应用的是一个授权码,随后客户应用在服务器端直接向授权服务器发起兑换授权令牌请求,这样才会获得真正的访问令牌。这种方式虽然复杂,但是你注意到访问令牌是客户应用服务器端代码直接发起的操作,并未通过终端代理,它提高了授权令牌的安全性。一般用于 Web 应用或者原生 App,这样 Token 就不会经过浏览器和 App,这样大大降低了 Token 泄漏的风险。

简化模式

这种方式是授权码模式的一个简化版本,资源所有者授权后,授权服务器直接将令牌发放至代理终端(例如浏览器),省去了授权码的流程。这种方式一般用于没有服务器的单页面应用,因为他们没有服务器端去拿授权码换取 Token。

密码模式

这种方式是资源拥有者直接将账户和密码告诉客户应用,客户应用使用账户和密码去授权服务器换取 T

作者正在撰写中...
隐藏内容 支付可见
¥9.99 购买
× 订阅 Java 精选频道
¥ 元/月
订阅即可免费阅读所有精选内容