基于OAuth2.0的第三方认证
理解OAuth 2.0:原理、分类
一张图搞定OAuth2.0:是什么,怎么用
应用自身,完成用户认证:
缺点:
1.不同的访问Web应用提供不同的用户凭证,对用户来说不方便
2.Web提供者,花费大量时间、精力、资源开发自己的认证系统。尤其每个子系统需要独立认证
值得信任的第三方能够提供一种免费的认证服务。
提供者均为值得信赖的IT服务提供商,比如微软、Google、Facebook、Twitter,以及国内的新浪、腾讯、网易、人人和豆瓣等。就目前来说,这些第三方认证服务绝大部分均是基于OAuth 2.0设计的。
OAuth的目的却是定义一种协议帮助资源的拥有者在不提供自身凭证的前提下授权第三方应用以他的名义存取受保护的资源。OAuth的全称为“Open Authorization”,所以它是一个开放的协议,目前最新的版本为2.0。
角色:
资源拥有者(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。
处理流程:
首先得取得资源拥有者的授权,所以第一轮消息交换旨在让客户端获得资源拥有者(即用户)的授权。客户端应用得到授权之后会得到一个被称为Authorization Grant的对象,该对象实际上就是一个简单的字符串用以表示成功取得了用户的授权。
接下来客户端应用利用此Authorization Grant向授权服务取获取用于访问受保护资源所需的Access Token。
在成功获得Access Token之后,客户端应用将其附加到针对资源服务器的请求中以获取它所需要的目标资源。
Authorization Grant:
代表一种中间凭证(Intermediate Credential),它代表了资源拥有者针对客户端应用获取目标资源的授权。
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适用于客户端应用获取属于自己的资源,换句话说客户端应用本身相当于资源的拥有者。
Implicit Authorization Grant授权流程:
用户会先被客户端应用重定向到授权服务器(login.live.com),具体的地址为“https://login.live.com/oauth20_authorize.srf”。
response_type: 表示请求希望获取的对象类型,在此我们希望获取的是Access Token,所以这里指定的值为“token”。
redirect_uri: 表示授权服务器在获得用户授权并完成对用户的认证之后重定向的地址,Access Token就以Hash(#)的方式附加在该URL后面。客户端应用利用这个地址接收Access Token。
client_id: 唯一标识被授权客户端应用的ClientID。
scope: 表示授权的范围,如果采用“wl.signin”意味着允许用户从客户端应用直接登录到Live Services,如果Scope为“wl.basic”则表示运行客户端应用获取联系人信息。如果读者朋友希望了解Windows Live Connect具体支持那些Scope,可以查阅Windows Live Connect API的官方文档。
授权服务器在获取用户的授权之后,会生成一个Access Token。
会提取请求中指定的重定向地址(即redirect_uri参数),然后将生成的Access Token以Hash(#)的形式附加在该地址后面,最终针对这个携带有Access Token的新地址返回一个重定向的响应。
重定向地址对应着客户端应用需要获取授权资源的页面,该页面可以直接从代表当前地址的URL中获得Access Token,并利用它来获取目标资源。对于我们的例子来说,它需要获取当前Windows Live帐号的基本信息,请求的地址为“https://apis.live.net/v5.0/me”,Access Token以查询字符串的形式(“?access_token={accesstoken}”)提供给资源服务器,后者据此验证请求的合法性并在验证成功的情况下将当前用户的基本信息以JSON的形式返回给客户端应用。
Authorization Grant存在这样的两个问题:
其一,授权服务器没有对客户端应用进行认证,因为获取Access Token的请求只提供了客户端应用的ClientID而没有提供其ClientSecret;
其二,Access Token是授权服务器单独颁发给客户端应用的,照理说对于其他人(包括拥有被访问资源的授权者)应该是不可见的。
Authorization Code Authorization Grant:
最为典型的Authorization Grant,它“完美”地实现了指定的OAuth初衷:资源拥有者可以在向客户端应用提供自身凭证的前提下授权它获取受保护的资源。
Authorization Code类型的Authorization Grant具有完整的“三段式”授权流程
Implicit类型的Authorization Grant授权的客户端运行于存客户端(浏览器)上下文环境,
Authorization Code类型的Authorization Grant则适用于运行于服务器的应用,比如ASP.NET MVC应用的Controller,或者是定义在View中的服务端程序。
客户端应用需要首先取得Authorization Code,因为它代表了资源拥有者对它的授权,并且是获取Access Token时必须提供的凭证。
首先向授权服务器发送一个获取Authorization Code的请求,请求的地址同样为“https://login.live.com/oauth20_authorize.srf”,相应的参数同样以查询字符串的形式提供。与Implicit类型Authorization Grant获取Access Token的请求一样,此时需要提供如下4个完全一样的参数。
如果当前用户尚未登录但Windows Live Services,他会被自动重定向到登录页面。在尚未对客户端应用进行授权的情况下,如左图所示的授权页面会显示出来。
在取得登录用户的授权之后,授权服务器会返回一个重定向的响应,而请求提供的redirect_uri参数值直接作为重定向地址。由授权服务器生成的Authorization Code就以查询字符串(?code={authorizationcode})的方式附加在重定向URL的后面。
重定向的请求被客户端应用接收后,Authorization Code被提取并保存起来。
接下来客户端应用会利用得到的Authorization Code向授权服务器获取Access Token,这一般为HTTP-POST请求。作为请求消息主体传递的内容除了作为参数“code”的Authorization Code之外,还包含如下一些必需的参数。
client_id: 唯一标识被授权客户端应用的ClientID。
client_secret:唯一标识被授权客户端应用的ClientSecret
redirect_uri:之前获取Authorization Code时指定的重定向地址。
grant_type:采用的Authorization Grant类型,参数值为“ authorization_code”。
授权服务器接受到请求之后,除了利用提供的ClientID和ClientSecrete对客户端应用实施验证之外,还会检验之前获取Authorization Code提供的ClientID和重定向地址是否与本次提供的一致。成功完成检验之后,授权服务器会生成一个Access Token作为响应内容发送给客户端应用。整个响应内容除了Access Token之外,还可以获取其他一些相关的信息,比如Access Token的类型(token_type)、过期时间(“expires_in”,单位为秒)、授权范围(“scope”,与获取Authorization Code时指定的一致)以及表示认证身份的安全令牌(“authentication_token”)。
客户端应用接受到响应之后从中提取出Access Token。当它试图获取受保护资源的时候,将此Access Token附加到请求上,便会以授权用户的名义得到它所需要的资源。
安全问题的解决:
虽然客户端获取Authorization Code时不需要指定ClientSecret,但是在获取Access Token时ClientRecret则是必需的,授权服务器只有在成功验证客户端应用身份的情况下才会颁发Access Token;
针对Access Token的消息交换仅限于授权服务器和客户端应用之间进行,所以第三方(包括 当前用户)都无法获取到正确的Access Token。
refresh token:
处于安全性考虑,Access Token并非终身有效,而是具有一个过期时间。上面我们给出了授权服务器返回Access Token的响应内容,其“expires_in”属性表示的就是Access Token的有效期限。那么,Access Token过期之后该如何处理呢?是否需要重新获得Authorization Code并利用它得到新的Access Token呢?
得到Authorization Code之后,可以在利用它获取Access Token的时候,让授权服务器一并返回一个叫做Refresh Token的令牌。与Access Token不同,Refresh Token是一个长期有效的安全令牌,当Access Token过期之后,我们可以利用它获取一个新的Access Token。
对于Windows Live Connection来说,如果希望在获取Access Token的时候让授权服务器返回一个Refresh Token,其指定的授权范围必须具有一个名为“wl.offline_access”的Scope,它表示允许客户端程序在任何时候(包括用户尚未登录Windows Live Connect的情况下)读取和更新用户信息。对于具有如此授权范围的Access Token请求,授权服务器返回的响应中会按照如下的形式包含Refresh Code的内容。
在客户端应用从响应内容成功提取出Refresh Token之后,可以在任何时候向授权服务器(地址依然是“https://login.live.com/oauth20_authorize.srf”)发送获取新的Access Token的请求。和直通过Authorization Code获取Access Token一样,这通常也是一个HTTP-POST请求
grant_type:采用的Authorization Grant类型,这里自然就是“ refresh_code”。
授权服务器对请求作必要验证后,会将新的Access Token置于响应的主体内容返回给客户端应用。完整地响应内容如下所示,我们不难看出:其中不仅仅包含新的Access Token,还返回了一个新的Refresh Token。
采用Authorization Code类型的Authorization Grant,客户端应用直接在Web服务器与授权服务器进行消息交换
基于OAuth2.0的第三方认证的更多相关文章
- 谈谈基于OAuth 2.0的第三方认证 [下篇]
从安全的角度来讲,<中篇>介绍的Implicit类型的Authorization Grant存在这样的两个问题:其一,授权服务器没有对客户端应用进行认证,因为获取Access Token的 ...
- 谈谈基于OAuth 2.0的第三方认证 [中篇]
虽然我们在<上篇>分别讨论了4种预定义的Authorization Grant类型以及它们各自的适用场景的获取Access Token的方式,我想很多之前没有接触过OAuth 2.0的读者 ...
- 谈谈基于OAuth 2.0的第三方认证 [上篇]
对于目前大部分Web应用来说,用户认证基本上都由应用自身来完成.具体来说,Web应用利用自身存储的用户凭证(基本上是用户名/密码)与用户提供的凭证进行比较进而确认其真实身份.但是这种由Web应用全权负 ...
- ASP.NET WebApi 基于OAuth2.0实现Token签名认证
一.课程介绍 明人不说暗话,跟着阿笨一起玩WebApi!开发提供数据的WebApi服务,最重要的是数据的安全性.那么对于我们来说,如何确保数据的安全将是我们需要思考的问题.为了保护我们的WebApi数 ...
- IdentityServer4之SSO(基于OAuth2.0、OIDC)单点登录、登出
IdentityServer4之SSO(基于OAuth2.0.OIDC)单点登录.登出 准备 五个Web站点: 1.localhost:5000 : 认证服务器.2 ...
- 微信公众平台开发 OAuth2.0网页授权认证
一.什么是OAuth2.0 官方网站:http://oauth.NET/ http://oauth.Net/2/ 权威定义:OAuth is An open protocol to allow s ...
- 基于OAuth2.0的token无感知刷新
目前手头的vue项目关于权限一块有一个需求,其实架构师很早就要求我做了,但是由于这个紧急程度不是很高,最近临近项目上线,我才想起,于是赶紧补上这个功能.这个项目是基于OAuth2.0认证,需要在每个请 ...
- 基于oauth2.0实现应用的第三方登录
OAuth2 OAuth2所涉及到的对象主要有以下四个: Client 第三方应用,我们的应用就是一个Client Resource Owner 资源所有者,即用户 Authorization Ser ...
- 基于OAuth2.0的统一身份认证中心设计
1. 引言 公司经历多年发展后,在内部存在多套信息系统,每套信息系统的作用各不相同,每套系统也都拥有自己独立的账号密码权限体系,这时,每个人员都需要记住不同系统的账号密码,人员入职和离职时,人事部门都 ...
随机推荐
- IO多路复用 IO异步
一.概念说明 同步IO和异步IO,阻塞IO和非阻塞IO分别是什么,到底有什么区别?不同的人在不同的环境给出的答案是不同的.所以先限定一下本文的环境.本文讨论的背景是Linux环境下的network I ...
- Ant打包可运行的Jar包(加入第三方jar包)
本章介绍使用ant打包可运行的Jar包. 打包jar包最大的问题在于如何加入第三方jar包使得jar文件可以直接运行.以下用一个实例程序进行说明. 程序结构: 关键代码: package com.al ...
- 【函数封装】javascript判断移动端操作系统为android 或 ios 或 iphoneX
function isPhone(){ var u = navigator.userAgent, app = navigator.appVersion; var isAndroid = u.index ...
- 小米note3的开发者选项在哪里?怎么进入开发者模式?如何显示布局边界?
小米note3的开发者选项在哪里?小米note3怎么进入开发者模式1.找到[设置],打开2.点击[我的设备]3.点击[全部参数]4.连续点击[MIUI版本]5次5.之后就会看见提示 “进入到开发者模式 ...
- linux 安装python3 date更新
http://linux.51yip.com/ ntpdate -u ntp.aliyun.com 更新时间 centos 默认是有 python的,是2.7.5的 重启网络的命令 -- sys ...
- 记账本微信小程序开发一
第一,在微信公众平台注册小程序账号并完善相关信息 第二,注册一个微信公众号,找到微信web开发工具并下载适合自己电脑的工具 第三,安装 第四,根据网上教程简单了解了开发工具的使用和布局
- oracle goldengate 远程捕获和投递
很早之前,OGG只支持部署在数据库主机上,这叫本地化部署.而现在OGG支持远端部署,即OGG软件不安装在数据库主机上,而是安装在单独的机器上,负责数据抽取和投递. 这样做的好处: l 易于管理 - 在 ...
- Python进阶【第五篇】函数式编程及某些特殊函数
一.函数式编程——Functional Programming 函数式=编程语言定义的函数+数学意义的函数 在计算机的层次上,CPU执行的是加减乘除的指令代码,以及各种条件判断和跳转指令,所以,汇编语 ...
- 4~20mA
4~20mA电流输出芯片XTR111完整电路 0-5v转0-20ma和0-5v转4-20ma 压控恒流源电路 4-20mA电流环路发送器入门
- Web开发笔记 #07# Swagger Editor
Swagger Editor是一款可以用yaml格式进行RESTful API设计.可视化.测试的工具,并且能够实时看到自动生成的文档.效果大概是这样的↓ 根据官方网站介绍,如果是团队的话,建议用在线 ...