OAUTH2概要.ppt

OAUTH 2.0 介绍 当前问题 第三方应用（如beeper）需要能访问到一些服务器托管资源（如消息服务器中的用户信息等资源）。这些资源通常都是受保护的，并且要求使用资源拥有者的私有证书（典型的证书是用户名和密码）进行身份验证。 安全问题 第三方应用需要用明文保存资源拥有者的私有证书，留作以后再次使用。 如：当前beeper与消息服务器公用的同一个数据库且拥有访问用户信息的权限，直接可以访问用户所有信息。 第三方应用对资源拥有者的受保护资源获得过多的使用权限，而资源拥有者没有能力限制访问到某个资源子集，限制持续时间，或限制这些资源所能支持的访问方式。 如：beeper服务器拥有用户在消息服务器上保存的所有资源，用户将无法限制beeper服务获取资源的权限。 资源拥有者无法在不影响所有第三方的前提下单独撤销某个第三方的访问权限，只能通过修改密码来回收所有权限。 如：beeper服务器拥有用户在消息服务器上保存的所有资源，用户即使修改自己的密码，也无法取消beeper的授权。 当前消息服务器收发消息没有做身份验证。 开发问题 开发者需要为每个服务器开发登录接口 解决方案 – 授权代理(oauth2) 概述 OAuth 为客户端提供了一种代表资源拥有者访问受保护资源的方法。 在客户端访问受保护资源之前，它必须先从资源拥有者获取授权（访问许可），然后用访问许可交换访问令牌（代表许可的作用域、持续时间和其它属性）。 客户端通过向资源服务器出示访问令牌来访问受保护资源。 基本概念 资源拥有者/用户(Resource Owner) 受保护的数据(如个人信息)或者服务的拥有人 一般是具体的用户 资源服务器(Resource Server) 提供资源的服务器，如保存了个人照片的服务器... 资源服务器通过服务接入提供对保护资源的访问 客户端/第三方应用(Client/3rd App) 拿资源拥有者的凭证去访问保护资源并再加工为资源拥有者提供更多的服务 授权服务器(Authorization Server) 用来认证授权并向第三方应用发放令牌的服务器 资源拥有者、第三方应用、资源服务器之间的授权代理 认证授权流程 (A). 客户端从资源拥有者那里请求授权。 (B). 客户端收到一个访问许可，它代表由资源服务器提供的授权。 (C). 客户端使用它自己的私有证书到授权服务器上验证，并出示访问许可，来请求一个访问令牌。 (D). 授权服务器验证客户端私有证书和访问许可的有效性，如果验证通过则分发一个访问令牌。 (E). 客户端通过出示访问令牌向资源服务器请求受保护资源。 (F). 资源服务器验证访问令牌的有效性，如果验证通过则响应这个资源请求。 Tips: - 资源服务器在收到服务请求时会与授权服务器交互验证该令牌有效性 如果令牌无效，会返回4xx异常 - 为提高执行效率，资源服务器一般会提供带时效的缓存来保存访问令牌，但是这样的负面作用是用户撤销授权后还会有一段时间服务依然会通过 具体实现 oauth2的四种实现方式 授权码授权(服务端WEB应用流程) 这是基于网页的授权方式。 客户端在请求验证前，需要先将浏览器跳转到用户授权页面，用户在登陆并确认授权后将浏览器Redirect到获得ClientID是注册的回调地址。这个地址中包含一个code参数。 用户根据该参数请求服务器获得Access Token。该认证授权流程包含了图片中的所有步骤。 隐式授权(客户端WEB应用流程) 这是一种适合JS等网页语言使用的认证方式。 这种认证方式比较简单，首先将页面引导至用户授权页面，用户授权后直接跳转到回调地址，并将Access Token作为地址参数传递给页面，方便脚本语言（JS）的访问。 用户密码凭证(资源拥有者密码凭证流程) 这是一种比较大的信任授权方式。 前提条件是用户对你的应用有绝对的信任，愿意在你的应用（Client）中输入自己的用户名和密码。 客户端通过用户名和密码进行验证，并得到Access Token。 客户端凭证(应用凭证流程) 对于不需要用户登陆就可以访问的资源，可以通过这种方式进行授权 授权码授权 适用场景 第三方应用是Web服务器 需要长时间访问资源 API 比较重要，避免访问令牌经过浏览器，减少泄漏可能 业务流程 用户在授权服务器认证和对应用授权 发放授权码(Authorization Code) 交换访问令牌(Access Token) 访问服务 刷新访问令牌 程序实现 步骤1：认证和授权 1、第三放应用发现没有授权时将用户转发到授权服务器的授权入口 redirect:http://localhost:60185/authori