OAuth:每次授权暗中保护你的那个“MAN”

摘要:OAuth是一种授权协议,允许用户在不将账号口令泄露给第三方应用的前提下,使第三方应用可以获得用户在某个web服务上存放资源的访问权限。 背景

在传统模式下,用户的客户端在访问某个web服务提供的具有一定访问限制的资源时,需要提供用于进行身份认证的凭证(credential),例如密码,accesskey等。如果存在第三方的应用需要该web服务上用户的资源,用户必须将自己的凭证共享给第三方应用,这种实践带来了一些问题:

第三方应用需要存放用户的凭证,且必须拿到明文(例如使用用户名和密码远程调用web服务的API),如果第三方应用被攻击,用户的凭证可能被泄露。

无法限制第三方应用的权限。第三方应用拿到用户凭证明文后,等于拿到了用户的所有权限,且用户无法对第三方应用在什么时间访问哪些资源进行限制,可能被越权。

用户无法回收对某个第三方应用的授权,除非更改密码。更改密码可能导致依赖该密码的其他第三方应用无法访问。

用户资源的安全性取决于安全性最弱的第三方应用(木桶理论),任何一个第三方应用被攻击,都可能导致用户的身份凭证泄露,以及存放在web服务上的资源被攻击。

基本原理

OAuth是一种授权协议,允许用户在不将账号口令泄露给第三方应用的前提下,使第三方应用可以获得用户在某个web服务上存放资源的访问权限。

例如下图,通过华为账号登录腾讯新闻应用时,并不需要将账号口令提供给腾讯新闻应用,用户只要拥有华为账号,只需要轻轻点击一下授权就可以无缝访问,在保证安全和隐私的同时带来体验上质的飞跃,体验提升的持续追求使得OAuth协议在互联网得到了非常广泛的应用。

OAuth:每次授权暗中保护你的那个“MAN”

OAuth通过引入authorization server的概念,并对授权访问过程中的几个参与方进行重新定义和角色解耦。

OAuth:每次授权暗中保护你的那个“MAN”

上面是一个非常非常抽象的流程图,仅仅为了厘清OAuth交互过程中存在哪些角色及承担的职责,实际上具体应用过程中的差异非常大。从上图大概可以看出,OAuth协议交互过程中存在四种角色:

resource owner

需要访问资源的主体,可以是人,也可以是物,指代人的时候就是我们通常说的end-user。

resource server

存放受保护资源的web服务,接收资源的访问请求并响应,resource server对请求进行鉴权。例如用户存放照片的华为终端云服务。

client

用来代理resource owner请求资源的应用程序,client访问资源需要得到resource owner的授权。例如照片美图APP,需要拉取用户存放在云服务上的照片。

authorization server

对resource owner进行身份认证和鉴权,并颁发访问凭证。例如华为账号认证服务。

其他说明

OAuth协议当前已经发展到0版本。1.0版本已经废弃,且OAuth2.0并不能后向兼容1.0。

OAuth协议常用于web访问,基于HTTP协议。实际上,OAuth只是定义了一种流程,以及该流程中各方的角色定义和功能职责,并不限于HTTP这一种传输通道。

上面的流程图中并没有介绍resource server和authorization server之间的交互,它们可能承载在同一个web服务中,也可能由不同的独立web服务承载。当resource server和authorization server各自独立时,正是因为OAuth协议没有定义其交互过程,导致OAuth协议在产品标准化和工程化中出现困难,后面会慢慢介绍。

OAuth:授权流程

接下来我们探讨一下,获取授权和获取token的几种模式,应用场景,交互过程以及API的定义。

分类

OAuth:每次授权暗中保护你的那个“MAN”

准备工作

在开始OAuth2.0的授权流程前,应用的开发者需要将应用的信息注册到authorization server,例如华为账号服务、百度开发者中心这些知名的开放平台,注册成功后得到最重要的两个参数:client_id和client_secret,这两个参数在后面介绍的几乎每种授权流程都会频繁使用。

如下图华为终端开发者联盟管理中心注册界面:

内容版权声明:除非注明,否则皆为本站原创文章。

转载注明出处:https://www.heiqu.com/wpzgpy.html