oauth2,0

2020-02-27 192浏览

  • 1.OAuth2.0 授权认证
  • 2.相片拥有 者 开放系统间授 权 云存储服 务 云冲印服
  • 3.资源拥有 者 客户应 用 受保护的资 源
  • 4.办法 1 ：密码用户名复 制 资源拥有 者 复制资源拥有者的用户名密码 ， 将它们传递到受保护的资 源 客户应 用 受保护的资 源
  • 5.办法 2 ：万能钥 匙 资源拥有 者 客户应 用 通用 developer key 可以加到 header 中认证 受保护的资 源
  • 6.办法 3 ：特殊令 牌 资源拥有 者 使用特殊的密码（或者令牌） ， 仅能访问受保护的资源 客户应 用 受保护的资 源
  • 7.传统单块应用安全（有状 态） 应用服务 器 用户名密 码 Cookie/Sessi on 过 滤 器 业 务 逻 辑 有状态服务在服务端保留之前请 求的信息 , 用以处 理当前 处处处处处 求,比 如 session 等（常常用与实现事 物） 用户 DB 登录授 权 业务 DB
  • 8.现代微服务安全（无状态） AuthN & AuthZ as a Service AuthServ er 用户 DB 浏览器单页应 用 服务 1 服务 3 无线原生 App 服务器端 App 服务 2
  • 9.你见过 OAuth 吗?
  • 10.总结： OAuth2 解决问题和场 景 开放系统间授 01 权 社交联合登录 02 03 开放 API 平 台 现代微服务安全 单页浏览器 App （ HTML5/JS/ 无状 态） 无线原生 App 服处处 器 端 WebApp 微服务和 API 间调 用 企业内部应用认证授权（ SSO ）
  • 11.OAuth2 定义和原 理
  • 12.有个资源服务器 负责管理用户数 据 资源服务 器 用户数据
  • 13.有个客户应用需要访问用户的数据 客户应 用 资源服务 器 用户数据
  • 14.给资源服务器按个门暴露用户数据称为 AP I 资源服务 器 客户应 用 AP I 用户数据
  • 15.客户应用可以通过 API 访问用户数 据 资源服务 器 客户应 用 “ 给我用户的数据” API 用户数据
  • 16.资源服务器返回用户数据 资源服务 器 客户应 用 “ 给我用户的数据” 用户数据 “ 给你数据” AP I 用户数据
  • 17.如果来了个恶意客户应用怎么办 资源服务 器 恶意客户应 用 AP I 用户数据
  • 18.即使恶意客户应用要求访问用户数据 资源服务 器 恶意客户应 用 “ 给我用户的数据” API 用户数据
  • 19.资源服务器还是返回用户数据 资源服务 器 恶意客户应 用 “ 给我用户的数据” 用户数据 AP I “ 给你数据” 恶意应用也能访问用户数 据 用户数据
  • 20.需要一种机制保护用户数据 资源服务 器 恶意客户应 用 “ 给我用户的数据” 用户数据 AP I “ 给你数据” 恶意应用也能访问用户数 据 用户数据
  • 21.业界实践是提前给客户应用处 处 一个 Access Token ， 它表示客户应用被授权可以访问用户数据 资源服务 器 客户应 用 Access Token AP I 用户数据
  • 22.访问用户数据时，给出 Access Token 客户应 用 Access Token Acces s Toke n “ 给我用户的数据” 资源服务 器 AP I 用户数据
  • 23.处源 服 处处处 器取出 处处处处 求中 的 Access Token 客户应 用 Access Token Acces s Toke n “ 给我用户的数据” 资源服务 器 AP I Acces s Token 用户数据
  • 24.并校验 Access Token 确认客户应用有访问 用户数据的权限 客户应 用 Access Token Acces s Toke n “ 给我用户的数据” 资源服务 器 AP I Acces s Token 校 验 用户数据
  • 25.校验通过后，资源服务器返回用户数据 客户应 用 Access Token 用户数据 Acces s Toke n “ 给我用户的数据” “ 给你数据” 资源服务 器 AP I Acces s Token 校 验 用户数据
  • 26.处 机 制可以工作的前提是 必须提前给客户应用颁发 Access Token 客户应 用 Access Token 用户数据 Acces s Toke n “ 给我用户的数据” “ 给你数据” 资源服务 器 AP I Acces s Token 校 验 用户数据
  • 27.需要颁发 Access Token 的角色 客户应 用 Access Token 用户数据 Acces s Toke n “ 给我用户的数据” “ 给你数据” 资源服务 器 AP I Acces s Token 校 验 用户数据
  • 28.谁颁发 Access Token 呢？ 授权服务器
  • 29.角色：一个授处 服 处处处 器，一个客户应用，一个资源服务器 处处处 生 成 Acces s Toke n 客户应 用 授 权 服 务 资 器 源 AP I 用户数据 服 务
  • 30.授权服务器负责生成 Access Token 生 成 Acces s Toke n 客户应 用 授 权 服 务 资 器 源 AP I 用户数据 服 务
  • 31.并将 Access Token 颁发给客户应用 客户应 用 Acces s Toke n 生 成 Acces s Toke n 颁 发 授 权 服 务 资 器 源 AP I 用户数据 服 务
  • 32.客户应用带上 Access Token 访问用户数据 客户应 用 Acces s Toke n 生 成 Acces s Toke n 颁 发 Access Token 授 权 服 务 资 器 源 AP I “ 给我用户的数据” 用户数据 服 务
  • 33.资源服务器从请求中取出 Access Token 客户应 用 Acces s Toke n 生 成 Acces s Toke n 颁 发 Access Token “ 给我用户的数据” AP I Acces s Toke n 用户数据 授 权 服 务 资 器 源 服 务
  • 34.校验 Access Token 具有访问用户数据的权限 客户应 用 Acces s Toke n 生 成 Acces s Toke n 颁 发 Access Token “ 给我用户的数据” AP I Acces s Toke n 校 验 用户数据 授 权 服 务 资 器 源 服 务
  • 35.校验 Access Token 具有访问用户数据的权限 客户应 用 Acces s Toke n 生 成 Acces s Toke n 颁 发 Access Token “ 给我用户的数据” AP I Acces s Toke n 校 验 “ 给你数据” 用户数据 授 权 服 务 资 器 源 服 务
  • 36.上面的流程中第一步是授权服务器生成 Access Token ， 在真实流程中，在颁发 Token 前先要征询用户同意 用 户 客户应 用 授 权 服 务 器
  • 37.首先客处 处 处 用处 处 求 Access Token 用 户 客户应 用 授 权 服 务 器
  • 38.授权服务器征询用户意见，是否将权限授予客户应用 “ 你是否同意将权限授予客户应用” 用 户 客户应 用 授 权 服 务 器
  • 39.如果用户同意授权服务器颁发 token 用 户 客户应 用 “ 你是否同意将权限授予客户应用” 授 “ 是的我同意” 权 服 务 器
  • 40.授权服务器生成一个 Access Token “ 你是否同意将权限授予客户应用” 用 户 客户应 用 “ 是的我同意” 生 成 Acces s Toke n 授 权 服 务 器
  • 41.并将 token 颁发给客户应用 “ 你是否同意将权限授予客户应用” 用 户 生 成 Acces s Toke n “ 是的我同意” 客户应 用 授 权 服 务 颁 发 器
  • 42.什么是 OAuth 2 .0 用于 REST/APIs 的代理授 权 框 架 (delegated authorization framework) 基于令牌 Token 的授权 ， 在无需暴露用户密码 的情 况下，使应用能获 取对用 户数据的有限访 问权限 事实上的标准安全框架， 支持多种用例场景 解耦认证和授权 • • • • 服务器端 WebApp 浏览器单页 SPA 无线 / 原生 App 服务器对服务器之间
  • 43.OAuth 并没有支持 HTTP 以外的协议 OAuth 并不是一个认 证协议 OAuth 并没有定义授权处理机 制 OAuth 并没有定义 token 格式 OAuth 2.0 并没 有定义 加密方法 OAuth 2.0 并不是单个协议 OAuth2.0 仅是授权框架，仅用于 授权代理
  • 44.典型 OAuth Flow 和选型
  • 45.授权码模 式 Resource Owner 阮一峰：理解 OAuth 2.0http://www.ruanyifeng.com/blog/2014/05/oauth_2_0.html < ------------- (B) Client Identifier ------ (A) ----------------------------------＆ Redirection URI ---------- > User-Agent ------ (B) ----------------------------------User authenticates --------- > Client Authorization Code >------ (D) -------------------------------------------- ‘ ＆ Redirection URI Access Token <------ (E) ------------------------------------------------------ ‘ (w/ Optional Refresh Token) > -------------- > < --(C) ------ ------ (C) ------------------------------------Authorization Code -------- < < ---------- --------- -(A) Authorization Server
  • 46.简化模 式 Resource Owner < --(B) ---- User-Agent ----(G) ---> < ----(A) ---- Client Client Identifier ------ (A) ----------------------------------＆ Redirection URI ---------- > ------ (B) -----------------------------------User authenticates --------- > ------ (C) ----------------------------------------Redirection URI with ---- < Access Token in Fragment Redirection URI ------ (D) -------------------------------without Fragment ------------> <---- (E)------------------- ----------Script ---------------< Authorization Server Web-Hosted Client Resource
  • 47.密码模 式 Resource Owner > ---- > ----- ) (A -- Client Redirection Owner Password Credentials Redirection Owner ----- > > ------ (B) ---------------------------------Password Credentials Access Token <------ (C)------------------------------------------ ---< (w/ Optional Refresh Token) Authorization Server
  • 48.客户端模 式 > ------ (A) --- ------------------------------Client Authentication ----- > Client <------ (B)--------------------------------------------< Access Token Authorization Server
  • 49.刷新令 牌 + + + ------------------------------ + <------ (B)----------------------------------------------------------------------Access Token ＆ Refresh ------ (A) --------- Authorization Grant ------------------------------ > Token + ------ (C) --------------------------------Access Token -------------- >+ Client Resource Server <------ (D)-------------------------------------Protected Resource --------- Authorization Server ------ (E) ---------------------------------------------- > Access Token <------ (F)-----------------------------------Invalid Token Error ----------- + + ------ (G) -------------------------------------------------------------------- > Refresh Token + Access Token <------ (H)----------------------------------------------------------------------+ + ＆ Optional Refresh Token +
  • 50.四种 OAuth 2.0 授权类型 (Fl ows) 授权码 Authorization 0 1 0 3 Code • 通处处 前端渠道 处 处 处客户 获取授权码 • 通过后端渠道，客户 使用 authorization code 去交换 access Token 和可选的 refresh token • 假定资源拥有者 和客户 在不同的设备上 • 最安全的流程，因为令牌不会传递经过 user-agent 用户名密码 Resource Owner Credentials • • • • 使用用处处 名密 处 处处 登处处 的处处 用，例如 处桌面 处处 App 使用用户名 / 密码作为授权方式从授权 服 务器上获取 access token 一般不支持 refresh tokens 假定资源拥有者和公开客户在相同设备 上 • • • • • 简化 Implicit 适用于公开的 处处器处处处处 用 Access Token 直接从授权服务器返回 （只有前端渠道） 不支持 refresh tokens 假定处处 源所有者和公开客 处 处 处 处 处 处 处 处处处 用在 同处一 个设 备上 最容易受安全攻击 客户端凭证 Client Credentials • • • 0 2 适用于服务器间通信场景，机密客户 代 表它自己或者一个用处 只有后端渠道，使用客户 凭证获取一 个 access token 因为客户 凭证可以使用对称或者非对 称 加密，该方式支持共享密码或者证 书 0 4
  • 51.授权类型选择 ~ 流 程 访问令牌 拥 有人 Implicit Grant 第三 方 第一还是 第 三方客 户 单页应用 SPA 第一 方 Resource Owner Credentials Grant 开 始 第一 方 机 器 Client Credentials Grant 用 户 客户类 型 原生 Ap p 第一还是 第 三方客户 Web 服务器端应 用 Authorization Code Grant 第三 方
  • 52.授权服务 器 Authorization Grant Authorize Endpoint (/oauth2/authorize) Token Endpoint (/oauth2/token) Refresh Token Introspection Endpoint (/oauth2/introspect) Access Token Revocation Endpoint (/oauth2/revoke) 授权服务器
  • 53.Spring Security OAuth2 架构
  • 54.OAuth2 客户端实操