前言
OAuth2.0授权框架让第三方应用获得了HTTP服务商的受限许可,要么通过组织在资源拥有者和HTTP服务商之间的被批准的交互动作代表用户,要么允许第三方应用代表用户获得访问的权限,这个说明书完全替代了之前过时的OAuth1.0协议的版本
目录
<!--[if !supportLists]-->1 <!--[endif]-->介绍(Introduction)
在传统的客户端-服务端认证模型中,客户端请求一个在服务器中许可受限的资源(受保护的资源)时,是使用的资源所有者的身份凭证与服务器进行验证.为了给第三方应用提供受限资源的访问权限,资源的拥有者可以与它分享他的身份凭证。但是这出现了一些问题和限制:
第三方应用需要储存资源拥有者的身份凭证以供将来使用,通常又是以一个明文方式
(某网站明文加密)
服务商需要支持密码验证,尽管密码存在固有的安全漏洞
(SB密码大量存在)
第三方应用程序获得过于广泛的访问资源拥有者的受保护资源的权限,让资源所有者没有任何能力限制持续时间或访问受限的子资源的权限。
(某些网站无法无天的利用用户的资源)
资源拥有者不能单独撤销一个第三方的访问权限而不影响其余的第三方,如果一定要这样做,只能通过修改第三方的密码
(牵一发动全身,有的允许,有的拒绝)
任何第三方应用收到危害都将导致最终用户的密码和所有被该密码保护的数据面临危害
(某网站被攻击了,难道我们也要跟着倒霉?)
Oauth通过引入授权层和从资源拥有者分离客户端角色来为这些问题定址。在Oauth协议中,客户端需要访问被资源拥有者控制的在资源服务器存储的资源,并且被发行一组不同的身份凭证,比资源拥有者的凭证还多。
为了替代直接使用资源拥有者的身份凭证去访问被保护的资源,客户端获得了一个access_token,它是一个字符串表示一个特点的范围,生命周期,和其他准入属性。Access_tokens通过授权服务器获得资源拥有者许可后被发布给第三方客户端。客户端使用access_token去访问存储在资源服务器上的被保护的资源。
譬如,一个end-user(资源拥有者)可以授予一个打印服务商(客户端)去访问她存储在图片分享服务端(资源服务器)的加密图片.相反,她直接授权给一个被图片分享网站(授权服务器)信任的服务,这个网站给这个打印服务特殊的授权凭证(access_token)
这个规格书为使用HTTP服务而设计。OAuth除了用在HTTP协议上,在其他任何协议上使用都是超出了范围。
Oauth1.0协议,作为一个信息文档发行,曾经是一个小的特别设计努力的结果。这个标准形成规范的文档是建立在Oauth1.0开发经验基础之上的,以及来自更广泛的IETF社区额外的用例和可扩展性需求。Oauth2.0协议不向后兼容Oauth1.0。这两个版本可能共存在网上,具体的实现也可能两者都支持。然而,该规格书的意图是本文档中指定的新实现方法只支持Oauth2.0,OAuth1.0只用于支持现存的项目。Oauth2.0协议分享很少的关于Oauth1.0的实现方法的详情。熟悉Oauth1.0协议的开发这应该多参考没有任何假设,结构和细节的文档。
<!--[if !supportLists]-->1.1<!--[endif]-->角色(Roles)
Oauth定义了四个角色
资源拥有者:
一个有授予访问受保护资源权限能力的实体。当这个资源拥有者是一个人时,通常被称为终端用户
资源服务器
这个服务器保存了受保护的资源,通过使用access_token请求能接收并返回受保护的资源
客户端
一个使用受保护资源的客户端请求代表资源拥有者,获得它的授权。这个术语”客户端”不意味任何特殊的实现特性(即无论这个应用是服务器执行,还是在桌面,或者其他设备上)。
授权服务器
这个服务器在成功验证资源拥有者并获取授权后给客户端发行access_tokens
在授权服务器和资源服务器之间的交互超过了该规格书的说明。这个授权服务器可能和资源服务器可能是一个服务器,也可以分开。一个单独的授权服务器可以发现被多种资源服务器接受的access_tokens。
<!--[if !supportLists]-->1.2<!--[endif]-->协议流(Protocol Flow)
+---------+ +----------------+
| |----(A)- Authorization Request -> | Resource |
| | | Owner |
| |<-(B)-- Authorization Grant ---- | |
| | +----------------+
| |
| | +----------------+
| |----(C)-- Authorization Grant --> | Authorization |
| Client | | Server |
| |<-(D)----- Access Token ------- | |
| | +----------------+
| |
| | +----------------+
| |----(E)----- Access Token ------> | Resource |
| | | Server |
| |<-(F)--- Protected Resource ----- | |
+---------+ +----------------+
图形1:协议流摘要
在插图1中OAuth2.0协议流摘要描述的四个角色之间交互动作如下概述:
<!--[if !supportLists]-->(A) <!--[endif]-->客户端向资源拥有者请求授权。这个授权请求可以被设计成直接指向资源拥有者(如图),最好还是间接通过授权服务器作为中介。
(直接告诉用户,诶,把淘宝网的账户给我用下呗。这么做肯定不合适吧!所有一般是通过淘宝的授权服务器去给用户一个弹出框。这活,腾讯喜欢干)
<!--[if !supportLists]-->(B) <!--[endif]-->客户端收到授权批准,它代表资源拥有者授权的凭证,使用该规格书中定义的四个批准类型中的一个,或者是一个延伸的批准类型。这个授权批准类型依靠客户端请求验证使用的方法和授权服务器支持类型。
(用户同意用QQ授权给这个应用,一般就把微博给他,好友列表给他啊等等,MD,信息就这么不要钱的给出去了。批准方法现在不多说)
<!--[if !supportLists]-->(C) <!--[endif]-->客户端通过验证授权服务器和提供授权批准方法来请求一个access_token。
(其实每个授权批准方法都会有返回值,现在感觉用得好复杂)
<!--[if !supportLists]-->(D) <!--[endif]-->授权服务器鉴定客户端和确认这个授权批准,如果合法,发放access_token。
(如何鉴定的,这才是最重要的吧!)
<!--[if !supportLists]-->(E) <!--[endif]-->客户端通过提供access_token从资源服务器请求受保护的资源和认证
(确实很绕,又是认证,又是授权,又是批准)
<!--[if !supportLists]-->(F) <!--[endif]-->资源服务器确认access_token,如果合法就服务它的请求。
客户端从资源拥有者获取授权批准(见图中A,B的步骤)的首选方法是把授权服务器作为一个中介,具体可以去见图形3 Section 4.1。
<!--[if !supportLists]-->1.3<!--[endif]-->授权批准(Authorization Grant)
一个授权批准其实就是一个凭证,它代表着资源拥有者的授权(访问受保护资源的权限)被客户端用于获得access_token。这个规格书定义了四种批准的类型——授权码(Authorization code),隐式(Implicit),资源拥有者密码凭证(resource owner password credentials),和客户端凭证(client credentials),也有可拓展的机制来定义额外的类型。
<!--[if !supportLists]-->1.3.1 <!--[endif]-->授权码(Authorization code)
授权码是通过使用作为客户端和资源拥有者间的中介授权服务器发放的。避免之前向资源拥有者请求授权,客户端尽量把资源拥有者引导到验证服务器(经由用户代理在RFC2616文中有定义),验证服务器引导用户携带授权码返回到客户端。
在引导用户携带授权码返回到客户端之前,验证服务器鉴定资源拥有者的正确性,并记录他的授权。因为资源拥有者仅仅和授权服务器进行鉴定,所有资源拥有者不会和客户端分享他的身份凭证
授权码提供少量的重要安全利益,例如鉴定客户端的能力,以及直接传送access_token给客户端,却不用通过资源拥有者的用户代理的许可,而且还有可能暴露给其他人,包括资源拥有者。
<!--[if !supportLists]-->1.3.2 <!--[endif]-->隐式(Implicit)
隐式批准是简化后的授权码流程,尽量帮助客户端在浏览器通过脚本语言的方式实
现,譬如JavaScript。在隐式流中,避免发行授权码给客户端,而是直接给客户access_token(资源拥有者授权后的直接结果)。这种批准类型叫隐式,没有发行中介凭证(譬如一个授权码,授权码一般用于获取access_token)
在隐式批准留着发行一个access_token,这个验证服务器是没有验证这个客户端的。在一些案例中,客户端的身份标识可以通过重定向URI(通常用于传送access_token给客户端)的方法进行验证。Access_token可以曝光资源拥有者或那些可以访问资源拥有者的应用的用户代理。
隐式批准提高了一些客户端的响应速度和处理效率(譬如那些网页嵌入应用的实现),是因为它减少获取access_token的往返次数。而然,这种使用隐式批准的应用带来的便利应该权衡下它的安全性。譬如我们在Section 10.3 和 10.16中描述的例子,尤其当授权码批准方法可以使用的时候
<!--[if !supportLists]-->1.3.3 <!--[endif]-->资源拥有者密码凭证(resource owner password credentials)
资源拥有者的密码凭证(也就是说,用户名和密码)可以直接用来当做授权批准去获得
access_token。这种凭证只能用在客户端和资源拥有者有很高的信任级别的场景中(例如,客户端是设备操作系统的一部分,或者是享有特权较高的应用),并且是在其他授权批准类型不可用的情况下。
尽管这种批准类型需要客户端访问资源拥有者的直接凭证,但是资源拥有者的凭证只能被一个请求所用,并且只能换一个access_token。这个批准类型可以消除客户端储存资源拥有者凭证以便以后使用的需求,通过用长久access_token或refresh_token交换凭证的方式。
<!--[if !supportLists]-->1.3.4 <!--[endif]-->客户端凭证(client credentials)
客户端凭证(或者是其他客户端鉴定的形式)可以被用作授权批准的方式,如下情况,
授权范围被限制在客户端控制下的,或者是之前被授权服务器安排的受保护的资源。
客户端凭证批准方式在客户端就是资源拥有者,或者基于授权服务器之前安排的授权请求访问受限资源的情况下被用作典型的授权批准类型
相关推荐
OAuth 2.0授权框架由互联网工程任务组(IETF)制定,由D. Hardt担任编辑,并在2012年10月发布为请求评论6749文档。该文档属于标准轨道类别,是IETF社区共识的体现,经过公开审查,并获得了互联网工程指导小组(IESG...
The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction ...
RFC6749,即《The OAuth 2.0 Authorization Framework》,是OAuth 2.0的官方标准文档,它详细定义了协议的各个方面,包括各个角色的交互过程、请求和响应格式、安全考虑等。中文译本和Markdown版本(RFC6749.zh_...
OAuth2.0协议主要解决了用户隐私和第三方应用安全访问的问题。该协议主要由RFC6749文档正式定义,此文档全称为"The OAuth 2.0 Authorization Framework"。RFC6749文档是由互联网工程任务组(IETF)发布的一系列指导...
### Play2.0 for Java Developers #### 概述 Play2.0是一个现代的Web应用框架,它基于Java和Scala语言构建,旨在提供简洁、快速且可扩展的应用开发体验。对于Java开发者而言,Play2.0提供了一套完整的Java API,...
在Spring Boot 2.0中,最重要的变化之一是基于Spring Framework 5.0,这意味着你可以利用Spring 5的新功能,如Reactor支持进行反应式编程,以及对Java 9和HTTP/2的全面支持。此外,Spring Boot 2.0还引入了对JPA 2.2...
ASP.NET Core 2.0提供了强大的身份验证服务,支持OAuth 2.0、OpenID Connect等协议,让开发者可以轻松地为应用添加安全功能。同时,它还支持角色和策略基础的授权,使得权限管理更加灵活。 除此之外,书中还会涵盖...
6. **OAuth2.0安全**: OAuth2.0是一种广泛使用的授权框架,用于保护Web服务的安全。在Spring Boot中,可以通过Spring Security来实现OAuth2.0,以实现端到端的安全通信。 7. **微服务最佳实践**: 微服务架构强调...
Chapter 13: OAuth 2.0 Protocol Securing our API Book Details Title: Zend Framework 2 Application Development Author: Christopher Valles Length: 298 pages Edition: 1 Language: English Publisher: Packt...
1. **身份验证与授权**:MVC 5内置了基于OAuth 2.0和OpenID Connect的身份验证系统,使得用户登录和权限管理更加安全便捷。同时,它支持OWIN(开放式Web接口.NET)中间件,允许开发者轻松集成第三方身份验证服务。 ...
- OAuth2.0:这是一种授权框架,允许第三方应用通过用户的授权获取访问令牌(access_token),进而获取和使用用户信息,提高了用户信息安全性和便捷性。 - CAS(Central Authentication Service):这是一种集中式...
- **OAuth 2.0**:流行的授权协议,用于第三方登录。 - **JWT (JSON Web Tokens)**:用于传递认证信息的安全标准。 #### 12. 网络请求与数据传输 - **RESTful API**:基于HTTP协议的服务接口,支持多种数据格式...
Spring Cloud Gateway是基于Spring Framework 5、Project Reactor和Spring Boot 2.0的全新网关服务框架,旨在为微服务架构提供一种简单有效的方式来进行路由、过滤和修改请求/响应。 **9. 什么是Spring Cloud Bus?...
它基于Spring Framework 5、Project Reactor和WebFlux,支持非阻塞式处理,提高了系统的吞吐量。 6. **控制总线**: Spring Cloud Bus可以用来广播配置更改或执行分布式系统中的其他操作。在2.0中,它加强了与其他...
在Spring Boot 2.0中,其集成更加紧密,配置更为简洁,且支持OAuth2和其他现代安全标准,确保应用的安全性。 随书源码通常会包含示例项目的完整实现,读者可以跟随书中章节逐步搭建和运行这些项目,加深理解并提高...
同时,OAuth2.0和OpenID Connect的增强使得身份验证和授权更为便捷。 6. **Spring Cloud Function** 这是Spring的一个新项目,专注于函数式编程。它允许开发者以函数形式编写业务逻辑,简化了微服务和事件驱动架构...
1. **身份认证与授权**:ASP.NET MVC 5集成了OAuth 2.0和OpenID Connect,使得用户身份验证更为简便。书中有详细的讲解,包括使用Cookie验证、基于声明的身份验证以及如何实现角色和权限控制。 2. **Entity ...