对于目前大部分Web应用来说,用户认证基本上都由应用自身来完成。具体来说,Web应用利用自身存储的用户凭证(基本上是用户名/密码)与用户提供的凭证进行比较进而确认其真实身份。但是这种由Web应用全权负责的认证方式会带来如下两个问题:

  • 对于用户来说,他们不得不针对不同的访问Web应用提供不同的用户凭证。如果这些凭证具有完全不同的密码,我们没有多少人能够记得住,所以对于大部分整天畅游Internet的网友来说,我想他们在不同的网站注册的帐号都会采用相同的密码。密码的共享必然带来安全隐患,因为我们不能确定Web应用本身是否值得信任。“信任危机”来源于两个方面:首先是对“人品”缺乏信任,我们不知道他们是否具有保护用户敏感信息的意愿;其次是对“能力”缺乏信任,即我们不清楚他们是否有能力保护用户的敏感信息,对于知名网站泄露用户帐号信息的情况我们实在已经看的太多了。
  • 对于Web应用的提供者来说,他们不得不对花费大量的时间、精力和资源来设计和开发自己的认证系统。在很多情况下,他们提供的是包含多个子系统的一整套解决方案,如果每个子系统均需要独立的认证,那么投入的成本可想而知。所以他们希望能够提供一个单一的“认证中心”来对整个“生态系统”提供认证,如果这个认证中心完全由第三方来免费提供,这无疑是最好的选择。

上面提出的这两点旨在说明一个问题:在Internet环境下,我们针对具体的Web应用设计独立的认证系统往往是一件“吃力不讨好”的事情。如果我们开发一个很小的Web应用,可能在实现用户认证功能上面花费的成本比实现应用自身业务功能的成本更大,而且还会因为“信任危机”导致潜在的使用者不敢注册。

在这种情况下,如果一个值得信任的第三方能够提供一种免费的认证服务,那么这两个问题均会迎刃而解。实际上目前这样的第三方认证服务很多,而且他们的提供者均为值得信赖的IT服务提供商,比如微软、Google、Facebook、Twitter,以及国内的新浪、腾讯、网易、人人和豆瓣等。就目前来说,这些第三方认证服务绝大部分均是基于OAuth 2.0设计的。

假设我有一件非常重要的文件存储与于瑞士银行的私有保险柜中,如果我需要委托某个人将他提取出来,除了将密码告诉他之外别无他法,但是OAuth的目的却是定义一种协议帮助资源的拥有者在不提供自身凭证的前提下授权第三方应用以他的名义存取受保护的资源。OAuth的全称为“Open Authorization”,所以它是一个开放的协议,目前最新的版本为2.0。

OAuth 2.0的角色

获得资源拥有者授权的第三方应用请求受保护的资源采用的不是授权者的凭证,所有一个被称为Access Token的安全令牌。Access Token颁发过程会涉及到若干不同的“实体”,它们在这个过程中扮演者不同的角色,我们通过一个具体的场景来认识一下该过程中涉及到的几种角色。

假设我们开发了一个集成了新浪微博认证的用于发布打折商品消息的App,经过用户授权之后它可以调用新浪微博的Web API获取用户的电子邮箱地址并发布相应的打折消息。那么OAuth 2.0在这个场景中的作用就在于:用户授权该应用以自己的名义调用新浪微博的Web API获取自己的电子邮箱地址,整个过程涉及到如下4种角色。

  • 资源拥有者(RO:Resource Owner):资源的拥有者也是授权者,如果它是一个“人”,一般就是指最终用户。由于“资源”在这个场景中表示为用户的电子邮箱地址,所以资源拥有者自然就是指最终用户。
  • 客户端应用(Client):需要取得资源拥有者授权并最终访问受保护资源的应用,对于我们的场景来说,就是我们创建的App。
  • 资源服务器(Resource Server):最终承载资源的服务器,它一般体现为一个可被调用的Web API。对于我们提供的场景来说,客户端通过调用新浪微博得Web API获得用户的电子邮箱地址,所以新浪微博就是资源服务器。
  • 授权服务器(Authorization Server):它对用户(一般情况下为资源拥有者)和客户端应用实施认证,并在用户授权的情况下向客户端应用颁发Access Token。在我们提供的场景中,资源服务器和认证服务器合二为一,均为新浪微博。

客户端凭证

一般来说,如果我们需要针对某种类型的第三方认证服务来开发我们自己的应用,我们需要向采用的认证服务提供商对该应用进行注册,注册成功之后会得到一个唯一标识该应用的ClientID和对应的ClientSecret(ClientID/ClientSecret是Windows Live Connect 的说法,Twitter和Facebook分别叫做ConsumerKey/ComsumerSecret和AppID/AppSecret。如果采用Google提供的OAuth 2.0 API,ClientID和ClientSecret是不需要的。)。它们相当于客户端应用的凭证,认证服务利用它们来确定其真实身份。

接下来我们简单演示一下如何为集成Windows Live Connect API的应用注册一个ClientID。我们利用浏览器直接访问https://account.live.com/developers/applications,如果当前用户尚未登录,浏览器会自动重定向到登录窗口。当我们采用某个Windows Live帐号完成登录之后,如下图所示的“Windows Live Developer Center”页面会呈现出来。

然后我们直接点击“Create application”连接创建一个新的应用。我们只需要在显示页面的“Application name”文本框中为创建的应用设置一个名称,同时在“Language”下拉框中选择适合的语言。如下图所示,我们为创建的应用取名为“AppDemo”。

当我们点击“I accept”按钮之后,应用被成功创建,相应的ClientID和ClientSecret也被生成出来。如下图所示,ClientID和ClientSecret的值分别为“000000004410A2A5”和“HeIrRmGyHHtMqhBDJipfGiauQnSHtYUX”。除此之外,我们要需要设置重定向地址的域名,Windows Live向客户端应用发送Access Token,以及其他数据采用的URI必须采用此域名,我们在下图中指定的域名为“https://www.artech.com”。域名成功设置之后,点击“Save”按钮之后整个注册工作结束。

处理流程

虽然OAuth 2.0具体采用的执行流程因采用不同类型的授权方式而有所不同,但是整个流程大体上由客户端应用分别与资源拥有者、授权服务器和资源服务器进行的3轮交互来完成。这个过程基本上体现在下图中,这被称为经典的“Three-Legged OAuth”。

客户端应用试图获取某个受保护的资源,首先得取得资源拥有者的授权,所以第一轮消息交换旨在让客户端获得资源拥有者(即用户)的授权。客户端应用得到授权之后会得到一个被称为Authorization Grant的对象,该对象实际上就是一个简单的字符串用以表示成功取得了用户的授权。接下来客户端应用利用此Authorization Grant向授权服务取获取用于访问受保护资源所需的Access Token。在成功获得Access Token之后,客户端应用将其附加到针对资源服务器的请求中以获取它所需要的目标资源。

Authorization Grant

OAuth 2.0的执行流程有点类似于的Kerberos认证:客户端先获得“认购权证”TGT(Ticket Granting Ticket),再利用TGT购买“入场券”ST(Service Ticket),最后凭借ST进行服务调用。对于OAuth 2.0来说,Access Token相当于Kerberos的ST,而Authorization Grant则与TGT具有相同的作用。

OAuth 2.0中的Authorization Grant代表一种中间凭证(Intermediate Credential),它代表了资源拥有者针对客户端应用获取目标资源的授权。OAuth 2.0定义了如下4种Authorization Grant类型,我们也可以利用定义其中的扩展机制定制其他类型的Authorization Grant。Authorization Grant的类型体现了授权采用的方式以及Access Token的获取机制。

  • Implicit:它代表一种“隐式”授权方式,即客户端在取得资源拥有者(最终用户)授权的情况下直接获取Access Token,而不是间接地利用获取的Authorization Grant来取得Access Token。换句话说,此种类型的Authorization Grant代表根本不需要Authorization Grant,那么上面介绍的“Three-Legged OAuth”变成了“Two-Legged OAuth”。
  • Authorization Code:这是最为典型的Authorization Grant,客户端应用在取得资源拥有者授权之后会从授权服务器得到一个Authorization Code作为Authorization Grant。在它获取寄宿于资源服务器中的目标资源之前,需要利用此Authorization Code从授权服务器获取Access Token。
  • Resource Owner Password Credentials:资源拥有者的凭证直接作为获取Access Token的Authorization Grant。这种Authorization Grant类型貌似与OAuth设计的初衷向违背(OAuth的主要目的在于让客户端应用在不需要提供资源拥有者凭证的情况下能够以他的名义获取受保护的资源),但是如果客户端程序是值得被信任的,用户(资源拥有者)向其提供自己的凭证也是可以接受的。
  • Client Credentials:客户端应用自身的凭证直接作为它用于获取Access Token的Authorization Grant。这种类型的Authorization Grant适用于客户端应用获取属于自己的资源,换句话说客户端应用本身相当于资源的拥有者。

什么是oauth2的更多相关文章

  1. Spring Security OAuth2 开发指南

    官方原文:http://projects.spring.io/spring-security-oauth/docs/oauth2.html 翻译及修改补充:Alex Liao. 转载请注明来源:htt ...

  2. OAuth2 理解

    OAth2 是为了某个应用向第三方应用开放服务时,控制权限的. 因为不可以直接将账户体系开放出去,要求重新登录. 其实本质是让用户在客户端来判断是否要给该应用开放平台的权限,如果用户同意,那么可以拿到 ...

  3. SimpleSSO:使用Microsoft.Owin.Security.OAuth搭建OAuth2.0授权服务端

    目录 前言 OAuth2.0简介 授权模式 (SimpleSSO示例) 使用Microsoft.Owin.Security.SimpleSSO模拟OpenID认证 通过authorization co ...

  4. 分享一个单点登录、OAuth2.0授权系统源码(SimpleSSO)

    SimpleSSO 关于OAuth 2.0介绍: http://www.ruanyifeng.com/blog/2014/05/oauth_2_0.html 系统效果: 登录界面: 首页: 应用界面: ...

  5. [转]Code! MVC 5 App with Facebook, Twitter, LinkedIn and Google OAuth2 Sign-on (C#)

    本文转自:https://www.asp.net/mvc/overview/security/create-an-aspnet-mvc-5-app-with-facebook-and-google-o ...

  6. 【OAuth2.0】Spring Security OAuth2.0篇之初识

    不吐不快 因为项目需求开始接触OAuth2.0授权协议.断断续续接触了有两周左右的时间.不得不吐槽的,依然是自己的学习习惯问题,总是着急想了解一切,习惯性地钻牛角尖去理解小的细节,而不是从宏观上去掌握 ...

  7. 深入理解OAuth2.0协议

    1. 引言 如果你开车去酒店赴宴,你经常会苦于找不到停车位而耽误很多时间.是否有好办法可以避免这个问题呢?有的,听说有一些豪车的车主就不担心这个问题.豪车一般配备两种钥匙:主钥匙和泊车钥匙.当你到酒店 ...

  8. ABP中使用OAuth2(Resource Owner Password Credentials Grant模式)

    ABP目前的认证方式有两种,一种是基于Cookie的登录认证,一种是基于token的登录认证.使用Cookie的认证方式一般在PC端用得比较多,使用token的认证方式一般在移动端用得比较多.ABP自 ...

  9. OAuth2.0 四种授权模式

    OAuth2.0简单笔记(四种授权模式) 金天:坚持写东西,不是一件容易的事,换句话说其实坚持本身都不是一件容易的事.如果学习有捷径,那就是不断实践,不断积累.写笔记,其实是给自己看的,是体现积累的一 ...

  10. 微信开放平台开发——网页微信扫码登录(OAuth2.0)

    1.OAuth2.0 OAuth(开放授权)是一个开放标准,允许用户让第三方应用访问该用户在某一网站上存储的私密的资源(如照片,视频,联系人列表),而无需将用户名和密码提供给第三方应用. 允许用户提供 ...

随机推荐

  1. cobbler部署以及使用

    常用软件安装及使用目录 资源链接:https://pan.baidu.com/s/1yfVnuSgY5vOTh-B74tpVyw   网盘分享的文件在此 cobbler第一次操作history. ec ...

  2. 用python实现数字图片识别神经网络--启动网络的自我训练流程,展示网络数字图片识别效果

    上一节,我们完成了网络训练代码的实现,还有一些问题需要做进一步的确认.网络的最终目标是,输入一张手写数字图片后,网络输出该图片对应的数字.由于网络需要从0到9一共十个数字中挑选出一个,于是我们的网络最 ...

  3. 实验三 敏捷开发与XP实践 实验报告 20135232王玥

    一.实验内容 1. XP基础 2. XP核心实践 3. 相关工具 二.实验要求 1.没有Linux基础的同学建议先学习<Linux基础入门(新版)><Vim编辑器> 课程 2. ...

  4. Sprint8

    进展:添加事件主界面实现之后,实现事件添加部分代码的编写,进行设置事件提醒,选择时间.

  5. spring冲刺计划

    会议召开时间表 日期 时间 内容 05/09 21:00-22:00 讨论题目(未果) 05/10 21:00-21:30 确定题目(网络助手) 05/13 21:00-21:45 讨论软件页面设计 ...

  6. sprint会议1

    昨天:进行第一次站立会议,讨论冲刺阶段,目标,任务认领,制作索引卡. 今天:准备查找安卓APP开发的有关资料,安装有关软件. 遇到的问题:对这方面毫无了解,不知道怎么开始,从哪开始,完全没经验.

  7. Task 6.2冲刺会议六 /2015-5-19

    今天主要写的是登陆界面,用户状态,历史登录信息,默认用户等等.由于大部分时间都是把代码组合拳起来的过程,所以总会出现各种bug,有好大一部分不会修复.明天要继续这一部分还有熟悉一下聊天的主界面.

  8. vm的三种网络模式

    Vm网卡的模式:网络地址转换模式(nat),仅主机(host-only),桥接模式(Brideged) VMware 的几个虚拟设备: ■ VMnet0:这是 VMware 用于虚拟桥接网络下的虚拟交 ...

  9. mongo学习1 (转)

    关于mongodb的好处,优点之类的这里就不说了,唯一要讲的一点就是mongodb中有三元素:数据库,集合,文档,其中“集合” 就是对应关系数据库中的“表”,“文档”对应“行”. 一: 下载 上Mon ...

  10. JDK和CGLIB动态代理原理

    1.JDK动态代理利用拦截器(拦截器必须实现InvocationHanlder)加上反射机制生成一个实现代理接口的匿名类, 在调用具体方法前调用InvokeHandler来处理. 2.CGLiB动态代 ...