oauth2,0

OAuth简单说就是一种授权的协议,只要授权方和被授权方遵守这个协议去写代码提供服务,那双方就是实现了OAuth模式。

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.0 http://www.ruanyifeng.com/blog/2014/05/oauth_2_0.ht ml < ------------- (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 客户端实操